1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
|
<chapter id="prog-guidelines"><title>Programming Guidelines</title>
<!--====== GENERALITES ======================================================== -->
<sect1 id="generalites"><title>Generalities</title>
<para>The presentation of a program indicates the quality of programming. This section relates to the common recommendations for the Tulip project. Each new programmer has to follow the expressed rules.</para>
<para>In the header files, the programmer should write a headline containing : his name with personal email adress (for students), the date of the last modifications, a reminder of the licence <acronym>GPL</acronym><footnote><para>General Public License</para></footnote> and the references of the code (for example, an algorithm). Header files must include a construction that prevents multiple inclusions. The convention is an all uppercase construction of the file name, the h suffix and prefixed by <quote>Tulip</quote>, separated by an underscore.
<programlisting>
#ifndef Tulip_MYTYPE_H
#define Tulip_MYTYPE_H
...
#endif // Tulip_MYTYPE_H
</programlisting></para>
<para>The organisation of files must be comprehensible. New module leads to a new set of files : a <filename>*.cpp</filename> and a <filename>*.h</filename> named with the name of the type. If the structure implicates that all methods are inline, the creation of a <code>.cxx</code> file is better than a <filename>.cpp</filename> file. The <filename>cxx</filename> should be included at the bottom of the header file. None implementation is in the header file. In the Tulip hiearchy, the cxx files are in a directory <quote>cxx</quote> in the header location. </para>
<para>The indentation is an important part for a easy reading in a file and a best understanding. Code must be properly indented to show the syntactic structure of the program. It is useless to space out excessively the code. A conventional indentation is just necessary. None useless <keycap>TAB</keycap> or spaces. The <keysym>{</keysym> caracter for the opening of a method or a function must be at the end of the line, not in following line. Each new fitted block of program implies a new shift for the indentation.</para>
<para>Each new module inserted in the Tulip library must be included in the namespace <code>tlp</code>. It is necessary in order to prevent eventually incompatibilities.
<programlisting>
namespace tlp{
/* code inserted */
}
</programlisting>
</para>
<para>Tulip is dependent of the <acronym>STL</acronym><footnote><para>Standard Template Library</para></footnote>. It provides a set of performing objects that you should use : vector, map, string, ... It exists two ways to use it. In the <filename>.h</filename> or <filename>.cxx</filename> files, you should preface them with the <code>std</code> namespace (e.g. <code>std::string s;</code>). You will refer them with the fullname : namespace and class name. For the <filename>.cpp</filename> files, you can use the short name if you insert the line at the top of your document <code>using namespace std;</code>.</para>
<para>
In a header file (<filename>.h</filename> or <filename>.cxx</filename>) :
<programlisting>
class MyClasse{
public:
Myclasse();
~MyClasse(){}
void draw();
private:
std::string mystring;
};
</programlisting>
In a source file (<filename>.cpp</filename>) :
<programlisting>
using namespace std;
MyClasse::MyClasse(){
mystring = "Hello world";
}
void MyClasse::draw(){
cout<<mystring<<endl;
}
</programlisting>
</para>
</sect1>
<!--================================================================================= -->
<!--====== NAMING =============================================================== -->
<sect1 id="naming"><title>Naming conventions</title>
<para> Programmer of Tulip has to follow some rules for choosing Type, Functions, or Variables names. Each names must be in English and choose to an easy understanding, descriptive and accurate. Each important word must be found in the name.
<itemizedlist><title>List of Rules</title>
<listitem><para>Types (struct, class, ...) : Names must be in mixed case starting with upper case. Each word should have first letter in upper case. Don't use underscore to separate words. (e.g. <code>SortedVector, OrientedList, RedBird, ...</code>)</para></listitem>
<listitem><para>Functions and Methods : Names must be in mixed case like for Types, but starting with lowercase. After the first one, each important word has first letter in upper case. Don't use underscore to separate words. (e.g <code>drawString(), computeFormulas(), ...</code>)</para></listitem>
<listitem><para>Variables : Names must be in lower case. (e.g. <code>instances, nodes, tableofcontents, ...</code>)</para></listitem>
<listitem><para>Constants : Names must be in upper case. (e.g. <code>MAXSIZE, BLACKCOLOR, ... </code>)</para></listitem>
<listitem><para>Macro and Enumeration constants : Names must be defined in upper case with an underscore between words. (e.g. <code>LAYOUTPLUGIN(C, N, A, D, I, V, R), ...</code>)</para></listitem>
<listitem><para>Namespaces : Names must be in lower case. (e.g. <code>tlp</code>)</para></listitem>
</itemizedlist>
The <emphasis>setter</emphasis> and <emphasis>getter</emphasis> must begin with the keyword <methodname>set</methodname> or <methodname>get</methodname>. All of the methods or functions should begin with a verb for understanding its goal. The prefix of a boolean variables or methods should be <emphasis>is, can, has, should</emphasis> : <methodname>bool isValid(const edge e) const</methodname>, function specified if the edge is valid.
</para>
</sect1>
<!--===================================================================================== -->
<!--======= COMMENTAIRES ================================================================ -->
<sect1 id="commentaires"><title>Code Comments</title>
<para>
All of the comments in the source and the header files must be written in the English language. Adding a lot of comments is a simple way to leave a clear code for the next programmer who will receive your work. A part of comments must be written with several rules to help the documentation of your work generating automatically with <emphasis>Doxygen</emphasis>. Choose a part of your comments to describe your work. See <xref linkend="doxygen"/>. It is important that a programmer can understand the using of your work and how to use your work.
</para>
<para>
Before a declaration of a class, you should write a little description to explain it. The role, the pre-requisites, the post-requisites, the return values and the parameters should be written before the declaration of the function or method. It is the minimum for an easy comprehension of your work.
In the code, it is useless to comment each line because the comments are often a paraphrase of the code. It just is essential to write a comment for strong parts that you have thought.
</para>
</sect1>
<!--=================================================================================== -->
<!--======= INTEGRATION ================================================================ -->
<sect1 id="integration"><title>Integration in Tulip project</title>
<para>The build of Tulip uses a mechanism of the GNU operating system. <acronym>GNU</acronym> has several tools used for the management of the configuration files. It modifies the <filename>makefile</filename> to adapt them to the distribution you have and the tools you need : the most important tools are <application>autoconf</application>, <application>automake</application> and <application>libtool</application>.
<application>Tulip</application> generates three libraries : <filename>libtulip, libtulip-ogl, libtulip-qt</filename>, a software : <filename>tulip</filename> and a script : <filename>tulip-config</filename>. In a thirdparty, <application>Tulip</application> compiles several external libraries needed by the software : ftgl, gle, gzstream, triangle.
</para>
<sect2 id="build-sys"><title>GNU Build system</title>
<sect3 id="presentation"><title>Presentation</title>
<para>The goals of this system is to simplify the development of portable programs and the building of programs that are distributed as source code.</para>
<para><application>Autoconf</application> is a tool of GNU producing shell scripts that automtically configure software packages to adapt to many kinds of UNIX systems. It is not the unique tool, it runs with others to solve all problems to making portable software. It generates configurations files : specially the <code>configure</code> script from a <filename>configure.in</filename> or <filename>configure.ac</filename> file. Running this script, you produce the customized Makefiles, and other files. It checks for the presence of each feature that the software need. Autoconf requires <application>GNU M4</application> in order to generate the scripts. </para>
<para>To this end, GNU has developed a set of integrated utilities to finish the job of <application>Autoconf</application>. <application>Automake</application> is the next in run. It is a tool for generating <filename>Makefile.in</filename> from files called <filename>Makefile.am</filename>. Each <filename>Makefile.am</filename> is basically a series of <code>make</code> variable definitions, with the GNU Makefile standards. <application>Automake</application> requires <application>Autoconf</application> in order to be used properly.
</para>
<para>The last is <application>Libtool</application>. It makes it possible to compile position independent code and build shared libraries in a portable manner. It does not require either Autoconf, or Automake and can be used independently. Automake however supports libtool and operates with it in a seamless manner.</para>
</sect3>
<sect3 id="simple-example"><title>A simple example</title>
<para>... to understand the basic mechanism.</para>
<para>To create a <filename>configure</filename> script with autoconf, you need so to write an autoconf input file <filename>configure.ac</filename> (or <filename>configure.in</filename>, use in previous versions of <application>Autoconf</application>). In this example, it is created a <filename>configure.ac</filename> file but Tulip contains <filename>configure.in</filename>. The both files are correct.
<programlistingco>
<areaspec>
<area id="programs" coords='9 30'/>
<area id="sources" coords='10 30' />
<area id="acinit" coords='13 30'/>
<area id="acsrcdir" coords='14 30'/>
<area id="acinitmake" coords='15 30'/>
<area id="progcc" coords='16 30'/>
<area id="output" coords='17 30'/>
</areaspec>
<programlisting>
`hello.c`
#include <stdio.h>
main(){
printf("Hello world!\n");
}
`Makefile.am`
bin_PROGRAMS = hello
hello_SOURCES = hello.c
`configure.ac`
AC_INIT(hello, 1.0)
AC_CONFIG_SRCDIR(hello.c)
AM_INIT_AUTOMAKE()
AC_PROG_CC
AC_OUTPUT(Makefile)
</programlisting>
<calloutlist>
<callout arearefs="programs"><para><code>bin_PROGRAMS</code> : specifies the name of programs that are building.</para></callout>
<callout arearefs="sources"><para><code>hello_SOURCES</code> : specifies the sources code that composed the program <quote>hello</quote>.</para></callout>
<callout arearefs="acinit"><para><code>AC_INIT</code> : initializes the <filename>configure</filename> script. It must be passed as argument the name of the package and the version.</para></callout>
<callout arearefs="acsrcdir"><para><code>AC_CONFIG_SRCDIR</code> : specifies a file in the source directory. <filename>configure</filename> script checks for the existence of this file to make sur that directory that it is told contains the source code in fact does. Any source file could do.</para></callout>
<callout arearefs="acinitmake"><para><code>AC_INIT_AUTOMAKE</code> : performs some further initializations that are related to the fact that we are using <application>Automake</application>. If you are writing your <filename>Makefile.in</filename> by hand, then you do not need to call this command.</para></callout>
<callout arearefs="progcc"><para><code>AC_PROG_CC</code> : checks to see which C compiler you have</para></callout>
<callout arearefs="output"><para><code>AC_OUTPUT</code> : tells the configure script to generate <filename>Makefile</filename> from <filename>Makefile.in</filename></para></callout>
</calloutlist>
</programlistingco>
Create the files and Run :
<screen>
$ aclocal
$ autoconf
</screen>
The <code>aclocal</code> command installs a file called `aclocal.m4'. It contains the knowned <application>Autoconf</application> macros to be in use in <filename>configure.ac</filename>, like <code>AC_PROG_CC</code>. If you want to include your macros, you can create an <filename>acinclude.m4</filename> file. An other cache directory is created to store the traces of the runs of <code>m4</code>. It is called <filename>autom4te.cache</filename>.</para>
<para>The <code>autoconf</code> command create the <filename>configure</filename> script. Then, Run :
<programlisting>
$ automake -a
</programlisting>
It displays :
<screen>
configure.ac: installing `./install-sh'
configure.ac: installing `./missing'
Makefile.am: installing `./INSTALL'
Makefile.am: required file `./NEWS' not found
Makefile.am: required file `./README' not found
Makefile.am: required file `./AUTHORS' not found
Makefile.am: required file `./ChangeLog' not found
Makefile.am: installing `./COPYING'
Makefile.am: installing `./depcomp'
</screen>
This creates copies of <filename>install-sh</filename>, <filename>missing</filename>, <filename>COPYING</filename>, <filename>depcomp</filename>. These files are required to be present by the GNU coding standards. But <filename>NEWS</filename>, <filename>README</filename>, <filename>AUTHORS</filename>, <filename>ChangeLog</filename> are not generated. You have to create them. If you have not them and you attempt to do <code>make distcheck</code>, then it will deliberately fail. To create it :
<screen>
$ touch NEWS README AUTHORS ChangeLog
</screen>
Then, you have to run <code>automake -a</code> a second time. This one has created a <filename>Makefile.in</filename> file from <filename>Makefile.am</filename>. In this file, we have specify what are building and the used sources. For a library, you should define the <filename>lib_LIBRARIES</filename> variable.
</para>
<para>Now the package is exactly in the state that the end-user will find it when person unpacks it from a source code distribution. To test you program, you can write :
<screen>
$ ./configure
$ make
$ ./hello
and ...
$ make install
$ make uninstall
$ make dist
...
</screen>
</para>
</sect3>
</sect2>
<sect2 id="files-adds"><title>File adds</title>
<para> To integrate a new module, set of types, in the Tulip project, you must to know which library is concerned : General library, OpenGL library, QT library, ... For each case, the procedure is the same. <filename>tulip/library/tulip-ogl/</filename> is the directory to integrate a library attached to the Opengl library. All of the <filename>.cpp</filename> files are pasted in the <filename>src</filename> subdirectory, the <filename>.h</filename> files in <filename>include/tulip</filename> and <filename>cxx</filename> files in <filename>include/tulip/cxx</filename>. Some modifications of your code should be necessary. The inclusion of files of Tulip project (included your work) is made with < and > because the compiler knows the path. For Tulip, the header files is in a special directory : <filename>tulip</filename>.</para>
<para><code>#include <tulip/TheFile.h></code> is an exemple of the inclusion. </para>
<para>So, you have to modify two files in the directory of your library to indicate the new files. <filename>include/Makefile.am</filename> is the first. You have to complete a variable containing all <filename>.h</filename> and <filename>.cxx</filename> files with your header files named <code>nobase_include_HEADERS</code>. This name is a choice for the processing of the GNU build system. The second one is <filename>src/Makefile.am</filename> and so, you complete the variable containing all <filename>.cpp</filename> files with your source files : <code>libtulip_ogl_la_SOURCES</code>, <code>libtulip_la_SOURCES</code> or <code>libtulip_qt_la_SOURCES</code> depending of the librairie you complete. You have modified the both <filename>Makefile.am</filename> but the Makefile not. To update it, you have to recreate the <filename>configure</filename> file at the root directory and run it again. To do it, run <code>./gen-conf</code> and <code>./configure</code>. To avoid this procedure at each modification of the <filename>Makefile.am</filename>, you can specify an option when you use <filename>configure</filename> script : <code>--enable-maintainer-mode</code>. See <xref linkend="options"/>, for more details about the options. Now, the next compilation includes your work.
</para>
</sect2>
<sect2 id="directive"><title>Compilation directives : Makefile.am</title>
<para>If you want to change the directive of compilation for a program or a library, then you have to complete or modify the variables attached to the program or library. This section gives the essential variables (with their forms) for a customized compilation.</para>
<para> <filename>Makefile.am</filename> can use the same syntax as with ordinary makefiles. General variable can be defined, available for all your building objects.
<variablelist>
<varlistentry><term><code>INCLUDES = -I/dir1 -I/dir2 -I$(top_srcdir)/src...</code></term>
<listitem><para>Insert the -I flags that you want to pass to your compiler when it builds executables.</para></listitem>
</varlistentry>
<varlistentry><term><code>LDFLAGS = -L/dir1 -L/dir2 ...</code></term>
<listitem><para> Lists all the library files that will be compiled with make and installed with <code>make install</code> under <code>prefix/lib</code>.</para></listitem>
</varlistentry>
<varlistentry><term><code>LDADD = MyClasse.o ... $(top_builddir)/dir1/libmylib.la ... -lmylib ...</code></term>
<listitem><para>List a set of object files, uninstalled libraries and installed libraries that you want to link in with all of your executables. Please refer to uninstalled libraries with absolute pathnames. Because uninstalled libraries are built files, you should start your path with <code>$(top_builddir)</code>.</para><para> There is a set of variables like <code>top_builddir</code> which are defined by <code>configure</code> when it processes a <code>Makefile</code> and they can be used in all others variables presented here.
<variablelist>
<varlistentry><term><code>srcdir</code></term>
<listitem><para>The relative path to the directory that contains the source code for that <code>Makefile</code>.</para></listitem>
</varlistentry>
<varlistentry><term><code>abs_srcdir</code></term>
<listitem><para>Absolute path of <code>srcdir</code>.</para></listitem>
</varlistentry>
<varlistentry><term><code>top_srcdir</code></term>
<listitem><para>The relative path to the top-level of the current build tree. In the top-level directory, this is the same as <code>srcdir</code>.</para></listitem>
</varlistentry>
<varlistentry><term><code>abs_top_srcdir</code></term>
<listitem><para>Absolute path of <code>top_srcdir</code>.</para></listitem>
</varlistentry>
<varlistentry><term><code>builddir</code></term>
<listitem><para>Rigorously equal to <quote>./</quote>. Added for the symmetry only.</para></listitem>
</varlistentry>
<varlistentry><term><code>abs_builddir</code></term>
<listitem><para>Absolute path of <code>builddir</code>.</para></listitem>
</varlistentry>
<varlistentry><term><code>top_builddir</code></term>
<listitem><para>The relative path to the top-level of the current build tree. In the top-level directory, this is the same as <code>builddir</code>.</para></listitem>
</varlistentry>
<varlistentry><term><code>abs_top_builddir</code></term>
<listitem><para>Absolute path of <code>top_builddir</code>.</para></listitem>
</varlistentry>
</variablelist>
</para></listitem>
</varlistentry>
</variablelist>
The following targets are used for a special directory or for special buildings:
<variablelist>
<varlistentry><term><code>bin_PROGRAMS = prog1 prog2 ...</code></term>
<listitem><para> Lists the executable files that will be compiled with <code>make</code> and installed with <code>make install</code> under <code>prefix/bin</code>, where <code>prefix</code> is usually <code>/usr/local</code> but you can specify to an other value.</para></listitem>
</varlistentry>
<varlistentry><term><code>lib_LIBRARIES = lib1.la lib2.la ...</code></term>
<listitem><para> Lists all the library files that will be compiled with make and installed with <code>make install</code> under <code>prefix/lib</code>.</para></listitem>
</varlistentry>
<varlistentry><term><code>SUBDIRS = dir1 dir2 ...</code></term>
<listitem><para> Lists all the subdirectories that we want to build before building this directory. <code>make</code> will recursively invoke itself in each subdirectory before doing anything on the current directory. If you mention the current directory <quote>.</quote> in <code>SUBDIRS</code> then the current directory will be built first, and the subdirectories will be build afterwards.</para></listitem>
</varlistentry>
<varlistentry><term><code>EXTRA_DIST = file1 file2 ...</code></term>
<listitem><para> Lists any files that you want to include into your source code distribution. </para></listitem>
</varlistentry>
<varlistentry><term><code>include_HEADERS = fich1.h fich2.h ...</code></term>
<listitem><para> Lists all the public header files in this directory that you want to install to <code>prefix/include</code>. If you change the keyword <code>include</code> by <code>noinst</code>, then you can specify headers that will not be installed.</para></listitem>
</varlistentry>
</variablelist>
For each progam, a set of variables should be declared :
<variablelist>
<varlistentry><term><code>prog_SOURCES = fich1.c fich2.c ...</code></term>
<listitem><para> Lists all the files that compose the source code of the program. Header files can be specified here.</para></listitem>
</varlistentry>
<varlistentry><term><code>prog_LDADD = $(top_builddir)/dir1/lib1.a -lext1 -lext2 ...</code></term>
<listitem><para> Lists the libraries that need to be linked with your source code. Installed libraries should be mentioned using '-l' flags. Uninstalled libraries must be mentioned using absolute pathnames. Please use <code>$(top_buiddir)</code> to build a path to a directory.</para></listitem>
</varlistentry>
<varlistentry><term><code>prog_LDFLAGS = -L/dir1 -L/dir2 -L/dir3 ...</code></term>
<listitem><para> Adds the '-L' flags that are needed to find the installed libraries that you want to link in <code>prog_LDADD</code>.</para></listitem>
</varlistentry>
<varlistentry><term><code>prog_DEPENDENCIES = dep1 dep2 dep3 ...</code></term>
<listitem><para>Lists any targets that you want to build before building this program.</para></listitem>
</varlistentry>
</variablelist>
In the same way, you can specify variable for a specialy library or shared library by prefixing the variable by the name of the library.</para>
<para>
Occasionally it is useful to know which Makefile variables that Automake uses for compilations. For instance you might need to do your own compilation in some special cases. Some variables are inherited from Autoconf; these are CC, CFLAGS, CPPFLAGS, DEFS, LDFLAGS, LIBS, CXX, CXXFLAGS, ... There are some additional variables which Automake defines itself:
<variablelist>
<varlistentry><term><code>AM_CPPFLAGS</code></term>
<listitem><para>The contents of this variable are passed to every compilation which invokes the C preprocessor; it is a list of arguments to the preprocessor. For instance, <code>-I</code> and <code>-D</code> options should be listed here. Automake already provides some <code>-I</code> options automatically. <code>AM_CPPFLAGS</code> is ignored in preference to a per-executable (or per-library) <code>_CPPFLAGS</code> variable if it is defined. </para></listitem>
</varlistentry>
<varlistentry><term><code>INCLUDES</code></term>
<listitem><para>This does the same job as <code>AM_CPPFLAGS</code>. It is an older name for the same functionality. This variable is deprecated; we suggest using <code>AM_CPPFLAGS</code> instead.</para></listitem>
</varlistentry>
<varlistentry><term><code>AM_CFLAGS</code></term>
<listitem><para>This is the variable which the Makefile.am author can use to pass in additional C compiler flags. It is more fully documented elsewhere. In some situations, this is not used, in preference to the per-executable (or per-library) <code>_CFLAGS</code>.</para></listitem>
</varlistentry>
<varlistentry><term><code>COMPILE</code></term>
<listitem><para>This is the command used to actually compile a C source file. The filename is appended to form the complete command line.</para></listitem>
</varlistentry>
<varlistentry><term><code>AM_LDFLAGS</code></term>
<listitem><para>This is the variable which the Makefile.am author can use to pass in additional linker flags. In some situations, this is not used, in preference to the per-executable (or per-library) <code>_LDFLAGS</code>.</para></listitem>
</varlistentry>
<varlistentry><term><code>LINK</code></term>
<listitem><para>This is the command used to actually link a C program. It already includes -o $@ and the usual variable references (for instance, <code>CFLAGS</code>); it takes as <quote>arguments</quote> the names of the object files and libraries to link in.</para></listitem>
</varlistentry>
</variablelist>
</para>
</sect2>
<sect2 id="prefix"><title>Variable prefix</title>
<variablelist>
<varlistentry><term><code>nobase_</code></term>
<listitem><para>e.g. <code>nobase_include_HEADERS</code>, mentionned that all the headers files will not be installed in the same place. It is possible to make subdirectories. <code>nobase_</code> should be specified first when used in conjunction with either <code>dist_</code> or <code>nodist_</code>.</para></listitem>
</varlistentry>
<varlistentry><term><code>noinst_</code></term>
<listitem><para>denotes data which do not need to be installed.</para></listitem>
</varlistentry>
<varlistentry><term><code>dist_ /nodist_</code></term>
<listitem><para>denotes files or data that will be included to the distribution (or not with <code>nodist_</code>).</para></listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2 id="gnu-ref"><title>References</title>
<para>Developing software with GNU : the GNU build system - <ulink url="http://www.amath.washington.edu/~lf/tutorials/autoconf/toolsmanual.html#SEC30"/></para>
<para>Autoconf Manual - <ulink url="http://www.gnu.org/software/autoconf/manual/"/></para>
<para>Automake Manual - <ulink url="http://www.gnu.org/software/automake/manual/"/></para>
</sect2>
</sect1>
<!--=================================================================================== -->
</chapter>
|
