> The important thing to know is that config.h/Makefile generation is
complex mainly because of API portability issues that have been mostly
obsolesced by increasing standardization around C99 and SuSv2 (the
Single Unix Standard, version 2, descended from POSIX).
Standardization on GNU Make has also addressed some (though not all)
of the portability issues in Makefiles.
Generating config.h was maybe a good idea in the 90s (I'm not convinced). But in this day and age it's a mistake.
These days all of my projects support Windows, mac, linux, and Android. Zero of them use autotools or generate a config.h. The whole concept of "discover capabilities of the system" is bad, broken, and these days unnecessary. Any type of "glue" code to abstract across slight differences between targets shouldn't be handled by the build system. It should be written by one person once ever and committed to source.
Building computer programs doesn't have to be complex and painful. The primary reason people think it's complex is because our build tools are stuck in the 90s.
Generating config.h was maybe a good idea in the 90s (I'm not convinced). But in this day and age it's a mistake.
These days all of my projects support Windows, mac, linux, and Android. Zero of them use autotools or generate a config.h. The whole concept of "discover capabilities of the system" is bad, broken, and these days unnecessary. Any type of "glue" code to abstract across slight differences between targets shouldn't be handled by the build system. It should be written by one person once ever and committed to source.
Building computer programs doesn't have to be complex and painful. The primary reason people think it's complex is because our build tools are stuck in the 90s.