First thing, you can run autoscan in the project's root directory. It will scan the project tree and generate configure.scan, while trying to detect non-portable features. Then you rename it to configure.ac, edit it accordingly and write Makefile.am files.
I suggest you look up this process (especially autoscan) in the GNU autotools manual for the details. It will reduce your effort, but at least you won't start from scratch with creating those files.
You are talking about two separate but intertwined things here:
- Autotools
- GNU coding standards
Within Autotools, you have several projects:
- Autoconf
- Automake
- Libtool
Let's look at each one individually.
Autoconf
Autoconf easily scans an existing tree to find its dependencies and create a configure script that will run under almost any kind of shell. The configure script allows the user to control the build behavior (i.e. --with-foo
, --without-foo
, --prefix
, --sysconfdir
, etc..) as well as doing checks to ensure that the system can compile the program.
Configure generates a config.h
file (from a template) which programs can include to work around portability issues. For example, if HAVE_LIBPTHREAD
is not defined, use forks instead.
I personally use Autoconf on many projects. It usually takes people some time to get used to m4. However, it does save time.
You can have makefiles inherit some of the values that configure finds without using automake.
Automake
By providing a short template that describes what programs will be built and what objects need to be linked to build them, Makefiles that adhere to GNU coding standards can automatically be created. This includes dependency handling and all of the required GNU targets.
Some people find this easier. I prefer to write my own makefiles.
Libtool
Libtool is a very cool tool for simplifying the building and installation of shared libraries on any Unix-like system. Sometimes I use it; other times (especially when just building static link objects) I do it by hand.
There are other options too, see StackOverflow question Alternatives to Autoconf and Autotools?.
Build automation & GNU coding standards
In short, you really should use some kind of portable build configuration system if you release your code to the masses. What you use is up to you. GNU software is known to build and run on almost anything. However, you might not need to adhere to such (and sometimes extremely pedantic) standards.
If anything, I'd recommend giving Autoconf a try if you're writing software for POSIX systems. Just because Autotools produce part of a build environment that's compatible with GNU standards doesn't mean you have to follow those standards (many don't!) :) There are plenty of other options, too.
Edit
Don't fear m4 :) There is always the Autoconf macro archive. Plenty of examples, or drop in checks. Write your own or use what's tested. Autoconf is far too often confused with Automake. They are two separate things.
Best Answer
ismail's solution is a common approach, but it suffers from some serious problems. If the user tries to get a debug build by doing './configure --enable-debug', the configure script will set CFLAGS to '-g -O2' and the Makefile will use '-g3 -O0 ... -g -O2' when building any executables. In that case, gcc will use -O2, and some compilers will abort because of the conflicting -O options. Either scenario is not the expected behavior.
Building with debug symbols or not is NOT something the project maintainer should worry about at all. This is an issue for the user. If you are building a project and you want to make a debug build or a release build, you should use different options at configure time. For example,
This will install a build with `-DDEBUG' and '-g -O0' (a "debug build") in /dbg/bin and a 'release' install in /usr/local/bin
You can reduce the tedium of the necessary typing by using a CONFIG_SITE file. For example, you can do:
and then all future invocations of 'configure --prefix=/dbg' will automatically inherit the settings to CPPFLAGS and CFLAGS without needing to be specified on the command line.
If, as the package maintainer, you want to provide the user with an easy way to build a "debug release", it is perfectly acceptable to include a script in the distribution that invokes the configure script with the appropriate arguments and invokes
make && make install
, but there is absolutely no need to litter your autotool metafiles with such cruft. It simply does not belong there. And be warned, many packages have made attempts to add--enable-debug
which are simply wrong. If the user invokesconfigure CFLAGS="-g -O0"
but gets a build that applies unexpected flags then you have a bug and your package is broken. This is an all too common experience, and if you maintain a package (currently thinking abouttmux
andcurl
) in which the user does not get what any reasonable person would call a "debug build" after invokingconfigure CFLAGS="-g -O0"
, then your package is broken.An important point that must always be remembered when maintaining a package with the autotools is that the user may be using a completely different tool chain than you are. It is entirely possible that the user's tool chain will require
-DMAKE_IT_A_DEBUG
or-DUSE_DEBUG
or-I/non/standard/path/to/headers
. Perhaps it will need-O145
or-Q
passed to the compiler or-debug
passed to the linker, or ... anything. As the maintainer, you simply do not have the information necessary to even make the phrase "debug build" meaningful for all users. So don't try, because you might make the software unbuildable for a certain set of users.