++ ++
(Note: For the actual development mode, see section 2 .)The GNU build system has two goals:
The first is to simplify the development of portable programs.
The second is to simplify the building of programs that are distributed as source code.
The first goal is achieved by the automatic generation of a 'configure 'Shell script, which configures the source code to the installer platform. the second goal is achieved by the automatic generation of makefiles and other shell scripts that are typically used in the building process. When we speak of the GNU build system we refer primarily to the following four packages: 1. autoconf produces a configuration shell script, named 'configure ', which probes the installer platform for portability related information which is required to customize makefiles, configuration header files, and other application specific files. then it proceeds to generate customized versions of these files from generic templates. this way, the user will not need to customize these files manually.
2. automake produces makefile templates, 'makefile. in 'to be used by Autoconf, from a very high level specification stored in a file called' makefile. am '. automake produces makefiles that conform to the GNU makefile standards, taking away the extraordinary effort required to produce them by hand. automake requires Autoconf in order to be used properly.
3. libtool 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 interoperates with it in a seamless manner.
4. autotoolset helps you develop portable source code that conforms to the GNU coding standards by generating varous boilerplate files from which you can plunge into developing your software. In a word, you can see the configure file, makefile template, and config template.
(1) For the user, the configure file is executed by the user to fill in the makefile template (for example, the compiler, the parameters used for linking, and the-D macro definition) and the config template (that is, change all # UNDEF to # define as needed ). This is just for the Purpose 1 above.
(2) For package developers, the makefile template is makefile. in. It is generated by writing makefile. am and then generated by automake. The Config template is config. h. in, the configure you wrote is scanned by autoheader. in, you can see which macros you want to detect, and generate the template file containing all macros, which is a piece of # undef xxx. The configure file is written to configure. in and then generated by Autoconf. This is just for Objective 2. While libtool is a separate tool, but it is embedded in automake, that is, libtool can be called in makefile. am. As for autotoolset, it is another tool set. Some work can be simplified:
1. building multidirectory software packages. it is much more difficult to use raw make recursively. having simplified this step, the developer is encouraged to organize per source code in a deep directory tree rather than lump everything under the same directory. developers that use raw make often can't justify the inconvenience of recursive make and prefer to disorganize their source code. with the GNU tools this is no longer necessary.
2. automatic configuration. you will never have to tell your users that they need to edit your makefile. you yourself will not have to edit your makefiles as you move new versions of your code back and forth between different machines.
3. automatic makefile generation. writing makefiles involves a lot of repetition, and in large projects very error-prone. also, certain portions of a good makefile, such as the 'install' and 'uninstall' targets are very critical because they are run by the superuser. they must be written without any bugs! The GNU build system automates makefile writing. You are only required to write 'makefile. am' files that are much more terse and easy to maintain.
4. support for Test suites. you can very easily write test suite code, and by adding one extra line in your 'makefile. am 'Make a check target available such that you can compile and run the entire test suite by running make check.
5. automatic distribution building. the GNU build tools are meant to be used in the development of free software, therefore if you have a working build system in place for your programs, you can create a source code distribution out of it by running make distcheck.
6. Shared libraries. building shared libraries becomes as easy as building static libraries. Two hats:
The developer HAT: You are the creator of the Code System and need to install the tools listed in a series of documents (automake, Autoconf ...)
The installer HAT: you are the user of the code and only want to install it. You only need make and shell. The difference between make DIST and make distcheck:
They are used to package the development directory in the current state and compress it into an installable package (configure, make, make install ). The former is basically packaging, and of course it will check whether some files are missing. In addition to packaging, the latter also tries some tests, including unpacking and simulating the user to run configure to check whether it is normal. Use distcheck if you want to perform multiple or custom checks (test suit. 5.4 understanding the Hello world example
This section is very important, depending on the details.
But in general, we need to write two files: makefile. Am and configure. In.
Makefile. am is a logical language without execution. The purpose is to simplify the compilation of makefile.
Configure. In is executed sequentially, and all macros added in it are used for execution. The purpose is to detect the system.
(For example, if you want to compile a C ++ program, you need to add the ac_prog_cxx macro. This macro will detect the G ++ compiler of the system and use this compiler to write the makefile .)
Let's look at the generated:
Configure: It is synthesized by aclocal. M4 and configure. in. The former is the macro definition in the latter. They use Autoconf to synthesize the configure file. Of course, aclocal. m4 must be generated with aclocal (aclocal actually goes to each of the/usr/share/aclocal directories. in the M4 file, go to your configure. macro definition used in, and copy it to generate aclocal. m4 file !)
Makefile: generated by configure and makefile. In. Of course, makefile. In must be generated by makefile. Am. makefile. In is translated into makefile. am, which is something to be determined. Configure converts makefile. In to makefile:
1. Replace some compiled macros, such as the compiler, compilation options... (this also reveals why autotools is used. The compilation chain tool on each platform is different from the compilation options. Not only is 2 and 2 a macro of the program, for example, a system does not support an API)
2. Replace the macros of some programs. The common method is to generate the header file containing # define, or pass the-D parameter to the compiler. Template: ── here is an example provided in the Manual, but the template I actually use has been updated. For details, see the acmkdir template below.
'Configure. in' Ac_init (hello. c) # Any file (initialize something)
Am_config_header (config. h) # Name of the generated configuration header file
Am_init_automake (hello, 0.1) # Make Dist package name and version number (used to initialize something related to automake)
Ac_prog_cc # Test C compiler type
Ac_prog_install # generate the install-sh "Installation tool" and install the make tool.
Ac_output (makefile) # indicates which directories should generate makefile. In. 'Makefile. am' Bin_programs = hello # What is the XX format? Here, read: the binary program has hello.
Hello_sources = Hello. c 'Hello. c'
# Ifdef have_config_h # What's going on? Of course-dhave_config_h is written in the makefile compiler command line.
# Include <config. h> # If am_config_header is not used, many parameters are directly transmitted using-dxxx instead
# Endif # Put It In config. h. For details, see the following description. # Include <stdio. h>
Main ()
{
Printf ("Howdy, pardner! /N ");
} To generate the configure file:
% Aclocal # provide configure. the actual macro script you write in, which actually goes to the/usr/share/aclocal directory. in the M4 file, go to your configure. macro definition used in, and copy it to generate aclocal. m4 file!
% Autoconf # generate the configure file
% Touch news readme authors changelog # automake requires these things
% Autoheader # generate the config. H. In Template for configure Filling
% Automake-A # generate the makefile. In Template for configure Filling
The above sequence is important. NOTE: If autoheader and am_config_header (config. h) are not used, the macros of all programs are transmitted to the compiler through-D. The following is the download compilation and link:
Gcc-dpackage_name =/"/"-dpackage_tarname =/"/"-dpackage_version =/"/"-dpackage_string =/"/"-dpackage_bugreport =/"/"-dpackage =/ "Hello/"-dversion =/"0.1/"-I. -G-O2-MT hello. o-MD-MP-MF. deps/hello. TPO-c-o hello. O hello. c
MV-F. deps/Hello. TPO. deps/Hello. Po
Gcc-g-O2-O hello. o
We can see that a large number of-D occurs. If autoheader and am_config_header are used, only-dhave_config_h is passed to GCC. Macros of other programs are stored in config. in the H file, and then the user in hello. in C, just include it. Below are the download compilation and links:
Gcc-dhave_config_h-I.-G-O2-MT hello. O-MD-MP-MF. deps/Hello. TPO-c-o hello. O hello. c
MV-F. deps/Hello. TPO. deps/Hello. Po
Gcc-g-O2-O hello. o Version:
Difference between 0.1 and 0.1.1:
0.1 is the official version: 0 indicates the main version, and 1 indicates the next version. The main version has been added, which requires great improvements in functions and stability. The next version is added. You only need to get rid of a bug.
0.1.1 is the unofficial version number. The last 1 indicates internal communication and use by the developer. For example, if a bug is changed and an achievement is calculated, a 1 is added to the end. If you want to become a mouse, you can use unofficial. Use acmkdir:
Acmkdir is one of the autotoolset tools. It helps you build a "project", that is, a directory containing the pile of files, similar to the Project Wizard of VC.
This can be used to save time. The usage is "acmkdir-t top-level directory type ".
The default type supports C ++ detection. Macros used in Configure. In (or. AC) are a series of LF headers.
If you want to use a traditional macro, you can-T traditional, so that you can see some familiar Macros in this manual. --------- How to use acmkdir to accelerate Project Creation :----------
It has only one engineering tree mode: The makefile. am at the top layer contains:
Extra_dist = reconf configure
Subdirs = M4 SRC Doc
Indicates that it will execute What You Want To Make in M4, SRC, and Doc.
Therefore, after using acmkdir, there are only three things to do:
(1) Modify Configure. AC as follows: (the reason for modification is that some macros are too large and some are missing)
Ac_init ([sheep], # project name, will be written to some files in./reconf
[0.0.1], # version number, written by yourself, will also be written to the file, and after the packaged name
[Yi Feng yifengcn@gmail.com], # first write the name of the author, then write the mailbox, will be written to the file, such as author
[Sheep]) # Name of the package. For example, make distcheck generates a sheep-0.0.1.tar.bz2
Ac_config_aux_dir (config) # store some auxiliary files in the config directory (otherwise, there are too many files in the top-level directory)
Am_config_header (config. h) # Description: Use config. h as the macro-defined file.
Am_init_automake ([dist-bzip2]) # Of course there are many parameters here, and [dist-bzip2] indicates packaging by bz2 packaging, the default is GZ
# Put It In config. h. For details, see the following description. Ac_prog_cc # Check the C compiler used
Ac_prog_cxx # Check the C ++ compiler used
Ac_prog_install # generate the installation script install-SH
Ac_prog_ranlib # Use ranlib (if you want to generate a Library)
Ac_prog_make_set # if your source files need to be organized by multi-level Directories Ac_config_files ([# location of all generated makefiles, which is actually for automake !!
Makefile # automake reads the configure. AC file and generates makefile. In
Readme
DOC/makefile
M4/makefile
Src/makefile
]) Ac_output # generate each makefile! (From each makefile. In) (2) Place your source file under SRC and modify makefile. Am under SRC.
Bin_programs = sheep
Sheep_sources = sheep. cpp
In the source file, write at the top:
# Ifdef have_config_h
# Include <config. h>
# Endif (3) go back to the top-level directory./reconf and click OK. The reconf content is as follows:
#! /Bin/sh
Rm-F config. Cache
Aclocal-I M4
Autoconf
Autoheader
Automake-
Exit Then, you can compile it in three steps. Of course, if you think it writes too many Configure. In items, you can change it by yourself. The author's suggestions on programming:
To avoid trouble, please do this:
(1) divide the problem into several sub-problems into one database.
(2) The remaining problems are testing and assembling databases into executable files.
In this case, there are many advantages-ease of testing, ease of troubleshooting, and easy to control the problem Scale Make distclean vs make clean:
Sometimes some changes are made to the file, such. c. CPP, you can't make the error inexplicably. In this case, make distclean. This will clear all the items produced by make, not just the target file. In fact, it is cleared, such. deps folder. The files in this folder have dependencies between the target file and the source file and the header file. If you only make clean, it will not be cleared. This occurs when the file name changes (such as from. c. CPP), which may lead to errors that cannot be made again. Save the error and try again. c, but cannot be found. |
