config.h considered harmful

Many, many programs written in C or C++ use a file called “config.h” which contains #define statement that control the compilation of the program. These programs are also nearly always built using ‘make’.

I claim that these two attributes are in conflict with each other. Or, in layman’s terms, “config.h sucks”. The problem is that when you have multiple options in config.h, every file which may be compiled differently depending on the values defined therein must be recompiled whenever config.h changes.

The correct way to do compile-time options is to have a config subdirectory containing a multitude of .h files, each with its own #define in it. These are easily managed because each file has only one #define, and when the source file mentions the thing being defined, it needs a #include of that config file. The ‘make’ program is trivially informed of these dependencies by looking at the header files included in each source.

So, when you change one option, only those files which depend on it will get recompiled.

I wrote this blog posting while waiting for a program to recompile because I changed config.h …. and it’s still not finished recompiling on pretty studly machine. Ahhhh, it just finished.

Of course, this is completely disrupted when you rewrite your Makefile (as GNU automake does), but that’s a subject for a different posting.