[1] https://zolk3ri.name/cgit/m4conf/about/
Nice job though.
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.
You mean build-time (with m4conf, that is).
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.
