m4conf obviously has messy configure scripts; they are just written in m4. For instance, it somes with a 120 kilobyte file m4sugar which is fully of m4 cruft.

Oh look, m4sugar.m4 is taken from GNU Autoconf and is GPLv3. The. m4conf project's master license doesn't mention this; it's a "BSD1" type license (like BSD2, but with no requirement for the copyright notice to appear in documentation or accompanying materials). Oops!

m4sugar says that it requires GNU m4, not just any POSIX m4.

I wrote the configure script in shell because that's what I decided I can depend on being present in the target systems. I deliberately rejected any approach involving m4 to show that a GNU style configure script can be obtained in as straightforward way, without convoluted metaprogramming.

There is a lot of copy-paste programming in my configure script, but it doesn't have to be that way; a script of this type can be better organized than my example. Anyway, you're not significantly disadvantaged writing in shell compared to m4, especially if you're mostly interested in probing the environment, not complex text generation.

I don't think that it's enough to test for header files being present. Almost all my tests target library features: including a header, calling some functions and actually linking a program. The contents of headers vary from system to system and with compiler options.

While m4sugar is from GNU Autoconf (which is GPLv3), it's properly listed as a dependency and ISC is GPL-compatible, so there's no licensing issue that I know of. The code explicitly seems to avoid GNU m4-specific features for BSD compatibility, and it goes well beyond header-only testing. While shell scripting is a valid approach, m4conf provides structured macros for maintainable configuration and advanced features like runtime CPU capability detection. As far as I can tell, the code is well-documented and organized, though you raise fair points about the tradeoffs between shell and m4 approaches, but as others have mentioned it (and seen in example m4 file), it is extremely simple to use and works with third-party libraries as well.

> runtime CPU capability detection

You mean build-time (with m4conf, that is).

m4conf is not using anything requiring GNU stuff though, and it has been tested with BSD m4 as well. It is noted in base.m4.

The license of m4conf itself is ISC.

m4sugar could be vetted so it is can become less than 120 KB.

I don't know if it is messy, look at the example configuration file. For me, it is more straightforward and less bloated than autotools, for example.

> I don't think that it's enough to test for header files being present. Almost all my tests target library features: including a header, calling some functions and actually linking a program. The contents of headers vary from system to system and with compiler options.

This is configurable as well in base.m4.

Perhaps an addition could be added, however, for third-party header files and functions.

I'll contact the author about this perhaps.

Oh and by the way:

> I don't think that it's enough to test for header files being present.

It checks for functions, too, not just header files, along with CPU features.

And "m4conf obviously has messy configure scripts" is not true, there are no scripts at all. Check out the examples. You cannot get any simpler.