Re:How to Write Portable C Without Complicating Your Build
by wahern on Friday March 31, 2017 @04:29PM
(#14007876)
I don't like plugging my projects on HN, but in this case I'll make an exception.
Though I've recently warmed to autoconf, I still agree it's overkill for most cases. For many years I have, like many others, maintained an ad hoc library of purely preprocessor-based feature checks that I would copy from project to project. When recently writing a comprehensive Unix system API module for Lua I basically ended up with a ridiculous number of feature checks. I broke those out into a separate project I called autoguess.
https://github.com/wahern/autoguess
Autoguess is a config.h file that exclusively uses preprocessor-based feature checks. It's very comprehensive. Much more comprehensive than most need, but compared to autoconf, or relative to modern C++ projects, all those preprocessor conditionals are effectively free.
autoguess doesn't provide any compatibility routines--just the detection. (For compatibility routines see my Lua module, lunix. Compatibility interfaces can be tricky, and context matters, so I've learned to stay away from trying to comprehensively "solve" that problem. One needn't look further than Gnulib to understand the pitfalls of trying to maintain such a beast.)
Most of the code in the autoguess repository is a framework for running autoconf checks and comparing feature detection results with the autoguess header. The library is just the single file "config.h.guess".
Autoguess uses the same naming conventions as autoconf, though in the autoconf universe consistency can be poor and HAVE_FOO names can differ from project-to-project. However, autoguess recommends to use "#if HAVE_FOO" arithmetic conditionals, not "#ifdef HAVE_FOO". That makes it possible to override feature detection macros from CPPFLAGS. Autoconf's rule about using #ifdef is an archaic solution to a mostly non-existent problem these days--broken C preprocessors not evaluating an undefined macro as 0 in arithmetic expressions. (There's a 6 line preamble at the top of configure.ac in my repository that will fix how autoconf generates config.h files.)
Of course, as new operating system releases are made, the autoguess checks can become outdated. Though many autoguess checks aren't directly reliant on version numbers, autoconf feature checking is, I agree, a more robust method. But autoconf checks aren't immune to regressions, either. There's no substitute for regularly building your software on various platforms.
Autoguess does much more than detect system and compiler versions, but I've benefitted greatly over the years from this project:
Though I've recently warmed to autoconf, I still agree it's overkill for most cases. For many years I have, like many others, maintained an ad hoc library of purely preprocessor-based feature checks that I would copy from project to project. When recently writing a comprehensive Unix system API module for Lua I basically ended up with a ridiculous number of feature checks. I broke those out into a separate project I called autoguess.
Autoguess is a config.h file that exclusively uses preprocessor-based feature checks. It's very comprehensive. Much more comprehensive than most need, but compared to autoconf, or relative to modern C++ projects, all those preprocessor conditionals are effectively free.autoguess doesn't provide any compatibility routines--just the detection. (For compatibility routines see my Lua module, lunix. Compatibility interfaces can be tricky, and context matters, so I've learned to stay away from trying to comprehensively "solve" that problem. One needn't look further than Gnulib to understand the pitfalls of trying to maintain such a beast.)
Most of the code in the autoguess repository is a framework for running autoconf checks and comparing feature detection results with the autoguess header. The library is just the single file "config.h.guess".
Autoguess uses the same naming conventions as autoconf, though in the autoconf universe consistency can be poor and HAVE_FOO names can differ from project-to-project. However, autoguess recommends to use "#if HAVE_FOO" arithmetic conditionals, not "#ifdef HAVE_FOO". That makes it possible to override feature detection macros from CPPFLAGS. Autoconf's rule about using #ifdef is an archaic solution to a mostly non-existent problem these days--broken C preprocessors not evaluating an undefined macro as 0 in arithmetic expressions. (There's a 6 line preamble at the top of configure.ac in my repository that will fix how autoconf generates config.h files.)
Of course, as new operating system releases are made, the autoguess checks can become outdated. Though many autoguess checks aren't directly reliant on version numbers, autoconf feature checking is, I agree, a more robust method. But autoconf checks aren't immune to regressions, either. There's no substitute for regularly building your software on various platforms.
Autoguess does much more than detect system and compiler versions, but I've benefitted greatly over the years from this project: