Debugging Autotools issues

From Gnash Project Wiki

Jump to: navigation, search

Rather than drop the usual RTFM, which I highly recommend anyway, here's a few tricks for debugging autotools issues. Other than the info pages for autoconf and automake, the Autotools book can also be very helpful.

Debugging Autoconf

Autoconf is just a giant shell script produced by simple pattern matching (using m4) with a series of templates that look sort of like function calls, but they're not. The scripting language is bourne shell, version 7 prefered for the best compatability.

The main debugging trick for configure scripts is to use the bourne shell's builtin debugging. This lists every line in the configure script as it's executed, expands variables, shows the setting of variable and the results of tests, and pretty much gives you the information (in huge volumes) that you want. To do this just run configure under a debugging shell "sh -x ./configure ....". You'll notice you don't get all the debugging messages you probably want, so you also have to se the subshell to also use debugging for the full effect. This is done by setting the environment variables CONFIG_SHELL to also be "sh -x".

I have aliases called cx and cs that toggle the value of CONFIG_SHELL, and then just always run configure like this "$CONFIG_SHELL ./configure ...".

Programming Suggestions

Don't do "if [ foo = bar ]; then", expand the bracket alias using the proper name of the utility like this "if test foo = bar; then". Using square brackets instead of test was added in later shells as a convienience, so it should be avoided.

Don't use the -z or -n options to test, these are also somewhatmore recent than v7 bourne shell. Instead test for empty variables using an extra character: "if test x"${foo}" = xyes; then". I also like to use curly braces around shell variable names, although some people prefer not too.

Be liberal with the use of brackets, as in m4 they are used as delimiters. These are not the same square brackets as used by the alias for the test utility. Pretty much anything between commas as arguments to the m4 template should be protectively wrapped. You can even use brackets instead of double quotes, as al lm4 does is blindly replace things when doing pattern substitution.

Use unique variable names as much as possible, as later when you're digging through reams of debugging output from the shell, it makes it much easier to find the part you want.

Debugging Automake

For debugging Makefiles, one useful tool is Remake. This is a debugger for Makefiles, and has much better support for seeing what is going wrong. If you want to see what is happening for a target, but get no output, try resetting the SHELL variable: make SHELL="sh -x" which will spew debugging messages from the subshell make starts to execute the commands to build the target.

Although usually the original source file, Makefile.am is short, you'll notice the output file, Makefile.in is huge. The reason why dates back to the early 1990s. At Cygnus, we supported GCC cross compilers that ran on many, many architectures. All of our Makefiles had shell script fragments buried in them to do dynamic testing of the many things that can effect a build, especially a cross build. Over time, all of the Makefiles hand copies of most of these little shell scripts, and creating a new Makefile was done by copying a working one and changing a few things. At that point some person realized that we might as well be generating the Makefiles from a template, rather than maintaining them by hand, as some of the Makefiles were over 8k in size.