Don't Fear the Autotools


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Don't Fear the Autotools

  1. 1. Dont Fear the Autotools!Scott GarmanPortland Linux User GroupDecember 1, 2011
  2. 2. AC_INIT([Scott Garman], [1.0], [])● Embedded Linux SW Engineer at Intel● Working on the Yocto Project (● I am not an Autotools fanboy; just a pragmatic user● I do not really know all that much about Autotools● Its just that knowing just enough about Autotools to be able to effectively work with it is a lot more than most people tend to know about it● This is a “gentle introduction” to hopefully inspire further study
  3. 3. What are “the Autotools?”● Cross-platform build system for compiled software (typically C/C++ applications)● Helps to encourage portability standards defined in the GNU Coding Standards (GCS) and Filesystem Hierarchy Standard (FHS)● The tools: ● Autoconf ● Automake ● Libtool
  4. 4. From a Users Perspective● tar xvzf application-1.0.tar.gz● cd application-1.0/● ./configure● make● sudo make install
  5. 5. The Most Common Configure Error● Configure script fails and reports an error such as: “No package libfoo found”● This indicates that you need to install library foo● “But I already have a package named libfoo installed!”● The runtime library is installed from package libfoo, but to compile applications which use foo, you need to install the “development headers” - this package is generally named libfoo-dev or libfoo-devel
  6. 6. Troubleshooting Configure Errors● When configure is run, it generates a log file config.log, which contains: ● Command line used to invoke configure ● Platform information about your environment ● Additional details about the tests configure ran ● A line number from the configure script where config.status is generated and run● Submitting config.log with a bug report to the application maintainers gives them important information they need to fix the issue
  7. 7. config.status● Uses information from configure to perform substitutions in *.in template files to generate the output files: configure config.log config.h config.status Makefile
  8. 8.● Running configure tests can take a while● If youre installing many apps from source, youll be running a lot of the same tests over and over again● Things like the size of a long int are not going to change on your system● A file can be created with seeded values for these tests, and will be used as a test result “cache”● Set an environment var CONFIG_SITE with the path to your file to make use of it● Very handy when cross-compiling apps (since some tests compile small C programs, but those programs cant be run natively!)
  9. 9. Filesystem Hierarchy Standard (FHS)● Defines root filesystem layout guidelines and where various file types belong● For example: the difference between binaries in /sbin vs. /usr/sbin● Widespread adoption by GNU/Linux distros has made portability of build systems easier● Current version is 2.3 (from 2004); v3.0 is now available in draft form●
  10. 10. GNU Coding Standards (GCS)● How source build configuration should work● Defines standard Makefile targets (install, dist, check, installcheck, etc)● Defines standard directory variables (bindir, libexecdir, sysconfdir, etc)● Standard command-line options (to promote consistent behavior among GNU utilities)● Good advice for how to write portable C code●
  11. 11. From a Developers Perspective● Autoconf: autoconf/autoreconf configure config.log config.h config.status Makefile
  12. 12. From a Developers Perspective● Automake: autoconf/autoreconf configure config.log config.h config.status Makefile automake/autoreconf
  13. 13. Hello World Example● Lets take a look at how to take a trivial C program (GNU amhello) and enable basic Autotools support
  14. 14. Libtool● Differences in how shared libraries are built across Unix systems are especially challenging to deal with● Very specific and unique compiler options are often needed on different platforms● Differences in library naming conventions● Libtool abstracts these details into a wrapper script that is invoked in uniform fashion to build libraries
  15. 15. Libtool Utilities● libtool – generic example script● libtoolize – creates a custom version of the libtool script that works with your program (; you then include this when distributing your sources● ltdl/ltdl.h – A standard way of loading shared libraries on-demand within your application (for when you want control over the process)
  16. 16. Why Use Autotools?● Attempting to address all of the subtle build failures that can occur between platforms yourself is an exercise in futility● Leverage the collective wisdom the project has attained, to result in portable shell scripts and makefiles which have minimal system requirements● Built-in support for following the GNU Coding Standards and FHS● Users and distro maintainers expect these features and already understand an Autotools-based build process
  17. 17. Resources● Autotools: A Practitioners Guide to GNU Autoconf, Automake, and Libtool, by John Calcote. No Starch Press.● Autotools Tutorial by Alexandre Duret-Lutz:● GNU Coding Standards:● Filesystem Hierarchy Standard:● Autoconf Macro Definitions: conf-Macro-Index.html