CMake Eugenia Loli 2003-12-22 General Development 16 Comments CMake is a project that aims at being a replacement for the GNU Build System (Autoconf, Automake and friends). Makefiles, autotools&CMake. By Sylvain Fargier. This document is only a brief introduction. Its goal is to give a global/overall. Convert an autotools project to CMake. Contribute to fritzone/autocmake development by creating an account on GitHub.
The GNU Autotools, also known as the GNU Build System, is a suite of programming tools designed to assist in making source codepackagesportable to many Unix-like systems.
It can be difficult to make a software program portable: the C compiler differs from system to system; certain library functions are missing on some systems; header files may have different names. One way to handle this is to write conditional code, with code blocks selected by means of preprocessor directives (#ifdef); but because of the wide variety of build environments this approach quickly becomes unmanageable. Autotools is designed to address this problem more manageably.
Autotools is part of the GNU toolchain and is widely used in many free software and open source packages. Its component tools are free software, licensed under the GNU General Public License with special license exceptions[1][2] permitting its use with proprietary software.
The GNU Build System makes it possible to build many programs using a two-step process: configure followed by make.[3]
Components[edit]
Autotools consists of the GNU utility programs Autoconf, Automake, and Libtool.[4] Other related tools frequently used alongside it include GNU's make program, GNU gettext, pkg-config, and the GNU Compiler Collection, also called GCC.
GNU Autoconf[edit]
Autoconf generates a configure script based on the contents of a configure.ac file, which characterizes a particular body of source code. The configure script, when run, scans the build environment and generates a subordinate config.status script which, in turn, converts other input files and most commonly Makefile.in into output files (Makefile), which are appropriate for that build environment. Finally, the make program uses Makefile to generate executable programs from source code.
The complexity of Autotools reflects the variety of circumstances under which a body of source code may be built.
- If a source code file is changed then it suffices to re-run
make, which only re-compiles that part of the body of the source code affected by the change. - If a
.infile has changed then it suffices to re-runconfig.statusandmake. - If the body of source code is copied to another computer then it is sufficient to re-run
configure(which runsconfig.status) andmake. (For this reason source code using Autotools is normally distributed without the files thatconfiguregenerates.) - If the body of source code is changed more fundamentally, then
configure.acand the.infiles need to be changed and all subsequent steps also followed.
To process files, autoconf uses the GNU implementation of the m4 macro system.
Autoconf comes with several auxiliary programs such as autoheader, which is used to help manage Cheader files; autoscan, which can create an initial input file for Autoconf; and ifnames, which can list C pre-processor identifiers used in the program.
GNU Automake[edit]
Automake helps to create portable Makefiles, which are in turn processed with the make utility. It takes its input as Makefile.am, and turns it into Makefile.in, which is used by the configure script to generate the file Makefile output. It also performs automatic dependency tracking; every time a source file is compiled, the list of dependencies (e.g., C header files) is recorded. Later, any time make is run and a dependency appears to have changed, the dependent files will be rebuilt.
GNU Libtool[edit]
Libtool helps manage the creation of static and dynamiclibraries on various Unix-like operating systems. Libtool accomplishes this by abstracting the library-creation process, hiding differences between various systems (e.g. Linux systems vs. Solaris).
Usage[edit]
Autotools assists software developers to write cross-platform software and make it available to a much wider user community, including in its source code form to those users who wish to build the software themselves. In most cases users simply run the supplied configure script (which has no dependencies other than the presence of a Bourne-compatibleshell), and then a make program.[5] They do not need to have the Autotools themselves installed on the computer.
It can be used both for building native programs on the build machine and also for cross-compiling to other architectures.[6]
Autotools For Windows
Cross-compiling software to run on a Windows host from a Linux or other Unix-like build system is also possible, using MinGW, however native compilation is often desirable on operating systems (such as the Microsoft Windows family of systems) that cannot run Bourne shell scripts on their own. This makes building such software on the Windows operating system a bit harder than on a Unix-like system which provides the Bourne shell as a standard component. One can install the Cygwin or MSYS system on top of Windows to provide a Unix-likecompatibility layer, though, allowing configure scripts to run. Cygwin also provides the GNU Compiler Collection, GNU make, and other software that provides a nearly complete Unix-like system within Windows; MSYS also provides GNU make and other tools designed to work with the MinGW version of GCC.
Although the developer is expected to provide a configure script for the end-user, occasionally the user may wish to re-generate the configure script itself. Such working might be necessary if the user wishes to amend the source code itself. Such users would need to have Autotools installed, and to use components such as its autoreconf.
The autoconf-generated configure can be slow because it executes programs such as a C compiler many times in order to test whether various libraries, header files, and language features are present. This particularly affects Cygwin, which, due to its lack of a native fork system call, may execute configure scripts considerably slower than Linux.[7]
Criticism[edit]
In his column for ACM Queue, FreeBSD developer Poul-Henning Kamp criticized the GNU Build System:[8]
The idea is that the configure script performs approximately 200 automated tests, so that the user is not burdened with configuring libtool manually. This is a horribly bad idea, already much criticized back in the 1980s when it appeared, as it allows source code to pretend to be portable behind the veneer of the configure script, rather than actually having the quality of portability to begin with. It is a travesty that the configure idea survived.
Kamp sketches the history of the build system in the portability problems inherent in the multitude of 1980s Unix variants, and bemoans the need for such build systems to exist:
the 31,085 lines of configure for libtool still check if and exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code.
Cmake Autotools For Mac
Responses to Criticism[edit]
Although critics of the Autotools frequently advocate for alternatives that provide greater simplicity to their users, some have argued that this is not necessarily a good thing. John Calcote, author[9] of the Autotools, 2nd Edition: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool, opined:[10]
The Autotools are actually more transparent than any other build tools out there. All these other tools' (cmake, maven, etc) - that purport to be so much simpler because they insulate the user from the underlying details of the build process - these tool's primary failure is that this very insulation keeps users from being able to make the changes they need to accomplish their unique project-specific build goals.
Anyone who has nothing but good things to say about this aspect of cmake, maven, gradle, or whatever, has simply not worked on a project that requires them to move far enough away from the defaults. I've used them all and I've spent hours in frustration trying to determine how to work around the shortcomings of some 'do-all' (except what I want) tool function. This is simply not an issue with the Autotools. As someone mentioned earlier in this thread, you can drop shell script into a configure.ac file, and make script into a Makefile.am file. That is the very definition of transparency. No other tool in existence allows this level of flexibility.
See also[edit]
References[edit]
- ^'Savannah Git Hosting - autoconf.git/blob - COPYING.EXCEPTION'. Git.savannah.gnu.org. Archived from the original on 2011-07-21. Retrieved 2016-04-01.
- ^'libtool.git - GNU Libtool'. Git.savannah.gnu.org. 2005-01-08. Retrieved 2016-04-01.
- ^'The GNU configure and build system - Introduction'. Airs.com. 1998-07-01. Retrieved 2016-04-01.
- ^'Learning the GNU development tools'. Autotoolset.sourceforge.net. Retrieved 2016-04-01.
- ^'automake: GNU Build System'. Gnu.org. 2014-12-31. Retrieved 2016-04-01.
- ^'Cross Compilation with GNU Autotools'. Archived from the original on October 13, 2008. Retrieved September 24, 2008.
- ^'Robert Ögren - Slow shell script execution on Cygwin'. Cygwin.com. Retrieved 2016-04-01.
- ^Kamp, Poul-Henning (2012). 'A Generation Lost in the Bazaar'. ACM Queue. 10 (8).
- ^'Autotools, 2nd Edition by John Calcote | Penguin Random House Canada'. Retrieved January 22, 2021.
- ^'Re: Future plans for Autotools'. Retrieved January 22, 2021.
External links[edit]
- The pkg-config package
The GNU Build System makes it possible to build many programs using a two-step process: configure followed by make.[3]
Components[edit]
Autotools consists of the GNU utility programs Autoconf, Automake, and Libtool.[4] Other related tools frequently used alongside it include GNU's make program, GNU gettext, pkg-config, and the GNU Compiler Collection, also called GCC.
GNU Autoconf[edit]
Autoconf generates a configure script based on the contents of a configure.ac file, which characterizes a particular body of source code. The configure script, when run, scans the build environment and generates a subordinate config.status script which, in turn, converts other input files and most commonly Makefile.in into output files (Makefile), which are appropriate for that build environment. Finally, the make program uses Makefile to generate executable programs from source code.
The complexity of Autotools reflects the variety of circumstances under which a body of source code may be built.
- If a source code file is changed then it suffices to re-run
make, which only re-compiles that part of the body of the source code affected by the change. - If a
.infile has changed then it suffices to re-runconfig.statusandmake. - If the body of source code is copied to another computer then it is sufficient to re-run
configure(which runsconfig.status) andmake. (For this reason source code using Autotools is normally distributed without the files thatconfiguregenerates.) - If the body of source code is changed more fundamentally, then
configure.acand the.infiles need to be changed and all subsequent steps also followed.
To process files, autoconf uses the GNU implementation of the m4 macro system.
Autoconf comes with several auxiliary programs such as autoheader, which is used to help manage Cheader files; autoscan, which can create an initial input file for Autoconf; and ifnames, which can list C pre-processor identifiers used in the program.
GNU Automake[edit]
Automake helps to create portable Makefiles, which are in turn processed with the make utility. It takes its input as Makefile.am, and turns it into Makefile.in, which is used by the configure script to generate the file Makefile output. It also performs automatic dependency tracking; every time a source file is compiled, the list of dependencies (e.g., C header files) is recorded. Later, any time make is run and a dependency appears to have changed, the dependent files will be rebuilt.
GNU Libtool[edit]
Libtool helps manage the creation of static and dynamiclibraries on various Unix-like operating systems. Libtool accomplishes this by abstracting the library-creation process, hiding differences between various systems (e.g. Linux systems vs. Solaris).
Usage[edit]
Autotools assists software developers to write cross-platform software and make it available to a much wider user community, including in its source code form to those users who wish to build the software themselves. In most cases users simply run the supplied configure script (which has no dependencies other than the presence of a Bourne-compatibleshell), and then a make program.[5] They do not need to have the Autotools themselves installed on the computer.
It can be used both for building native programs on the build machine and also for cross-compiling to other architectures.[6]
Autotools For Windows
Cross-compiling software to run on a Windows host from a Linux or other Unix-like build system is also possible, using MinGW, however native compilation is often desirable on operating systems (such as the Microsoft Windows family of systems) that cannot run Bourne shell scripts on their own. This makes building such software on the Windows operating system a bit harder than on a Unix-like system which provides the Bourne shell as a standard component. One can install the Cygwin or MSYS system on top of Windows to provide a Unix-likecompatibility layer, though, allowing configure scripts to run. Cygwin also provides the GNU Compiler Collection, GNU make, and other software that provides a nearly complete Unix-like system within Windows; MSYS also provides GNU make and other tools designed to work with the MinGW version of GCC.
Although the developer is expected to provide a configure script for the end-user, occasionally the user may wish to re-generate the configure script itself. Such working might be necessary if the user wishes to amend the source code itself. Such users would need to have Autotools installed, and to use components such as its autoreconf.
The autoconf-generated configure can be slow because it executes programs such as a C compiler many times in order to test whether various libraries, header files, and language features are present. This particularly affects Cygwin, which, due to its lack of a native fork system call, may execute configure scripts considerably slower than Linux.[7]
Criticism[edit]
In his column for ACM Queue, FreeBSD developer Poul-Henning Kamp criticized the GNU Build System:[8]
The idea is that the configure script performs approximately 200 automated tests, so that the user is not burdened with configuring libtool manually. This is a horribly bad idea, already much criticized back in the 1980s when it appeared, as it allows source code to pretend to be portable behind the veneer of the configure script, rather than actually having the quality of portability to begin with. It is a travesty that the configure idea survived.
Kamp sketches the history of the build system in the portability problems inherent in the multitude of 1980s Unix variants, and bemoans the need for such build systems to exist:
the 31,085 lines of configure for libtool still check if and exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code.
Cmake Autotools For Mac
Responses to Criticism[edit]
Although critics of the Autotools frequently advocate for alternatives that provide greater simplicity to their users, some have argued that this is not necessarily a good thing. John Calcote, author[9] of the Autotools, 2nd Edition: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool, opined:[10]
The Autotools are actually more transparent than any other build tools out there. All these other tools' (cmake, maven, etc) - that purport to be so much simpler because they insulate the user from the underlying details of the build process - these tool's primary failure is that this very insulation keeps users from being able to make the changes they need to accomplish their unique project-specific build goals.
Anyone who has nothing but good things to say about this aspect of cmake, maven, gradle, or whatever, has simply not worked on a project that requires them to move far enough away from the defaults. I've used them all and I've spent hours in frustration trying to determine how to work around the shortcomings of some 'do-all' (except what I want) tool function. This is simply not an issue with the Autotools. As someone mentioned earlier in this thread, you can drop shell script into a configure.ac file, and make script into a Makefile.am file. That is the very definition of transparency. No other tool in existence allows this level of flexibility.
See also[edit]
References[edit]
- ^'Savannah Git Hosting - autoconf.git/blob - COPYING.EXCEPTION'. Git.savannah.gnu.org. Archived from the original on 2011-07-21. Retrieved 2016-04-01.
- ^'libtool.git - GNU Libtool'. Git.savannah.gnu.org. 2005-01-08. Retrieved 2016-04-01.
- ^'The GNU configure and build system - Introduction'. Airs.com. 1998-07-01. Retrieved 2016-04-01.
- ^'Learning the GNU development tools'. Autotoolset.sourceforge.net. Retrieved 2016-04-01.
- ^'automake: GNU Build System'. Gnu.org. 2014-12-31. Retrieved 2016-04-01.
- ^'Cross Compilation with GNU Autotools'. Archived from the original on October 13, 2008. Retrieved September 24, 2008.
- ^'Robert Ögren - Slow shell script execution on Cygwin'. Cygwin.com. Retrieved 2016-04-01.
- ^Kamp, Poul-Henning (2012). 'A Generation Lost in the Bazaar'. ACM Queue. 10 (8).
- ^'Autotools, 2nd Edition by John Calcote | Penguin Random House Canada'. Retrieved January 22, 2021.
- ^'Re: Future plans for Autotools'. Retrieved January 22, 2021.
External links[edit]
- The pkg-config package
I think I am finally warming up to CMake.
Eight years ago (at FOSDEM 2010), I gave a talk on build systems that explainsthe fundamentals of automake, autoconf and libtool:
There is nothing in this talk that is no longer valid today as far as I can see,though CMake was 'newfangled' then and is a lot less so today. In any case, myconclusion still stands:
- Don't try to reinvent the wheel, use a popular build system.
- You cannot write a portable build system from scratch – so don't try.
My advice came from pent-up frustration over software that does not build on myplatform (MirBSD, at the time) but remains true today. And to be clear:
Autotools is still a good choice for new code.
CMake
However, recent experience has made me like CMake a lot more. For one, it ismore common today, which means that packaging systems such as pkgsrc have goodsupport for using it. For instance, in a pkgsrc Makefile, configuring usingCMake is as easy as specifying
As the user of a package (i.e. the person who compiles it), CMake builds arecompelling because they (a) configure faster and (b) build faster.
Regarding configuring, it is infuriating (to me) how the run time of theconfigure script in autotools totally dominates build time, as long as you runmake -j12 or similar. CMake typically checks fewer things (I think) and doesnot run giant blobs of shell, so it is faster.
For the latter, I have noticed that CMake builds typically manage to use all thecores of the machine, while automake-based builds do not. I think (again, thisis speculation) that this is because automake encourages one Makefile perdirectory (which are being run sequentially, not in parallel) and one directoryper target, while CMake builds all in one go. Automake can do one Makefile forall directories too, but support for that was added only a few years ago, and itseems rarely used.
CMake builds also have different diagnostics (console output), optionally incolor. Some people hate the colors, and they can be garish, but I do like thepercentages that are shown for every line.
Concrete case: icewm
When I recently packaged wm/icewm14, I noticed that you now have the choiceof CMake or autotools, and I ended up with CMake. There were a few things tofix but its CMakeLists.txt file is reasonably easy to edit. Note that itcontains both configuration tests and target declarations. Here is a smallexample:
Compared to the same thing in automake:
So if anything, the syntax is no worse but the result is a bit better. I wasable to rummage around in CMakeLists.txt without reading any documentation.
