Paul Smith wrote:
> Here's what I find extremely difficult to manage regarding gnulib's
> current design:
>
> - Heavy reliance on .in files that need to be transformed.
>
> On systems that aren't POSIX and don't have ready access to sed or
> similar tools, this is very annoying to deal with.
>
> The original design of autoconf, where there was a single config.h
> which defined a ton of #define values that were then tested by other
> files, was far simpler for non-traditional systems: you merely had to
> create a pre-defined config.h file for such a target (most of the time
> these targets were homogeneous enough across releases that they didn't
> require autoconf anyway) and arrange to have the file renamed to start
> the build process.
>
> However with gnulib's current design for the replacement system headers
> (at least) instead of using the old-style '#if !HAVE_BOOL' (as on
> example from stdbool.in.h), they use:
>
> # if !@HAVE__BOOL@
I think you are barking up the wrong tree.
In the other mail I've explained how you can reduce the number of build
systems you use from 3 (Autoconf+Automake, Windows nmake, VMS nms) to
one (Autoconf+Automake).
The step that you underestimate here is "you merely had to
create a pre-defined config.h file for such a target". Gnulib-generated
header files (such as glob.h) use many more autoconf tests (such as
whether a function exists, is declared, has specific bugs). If someone
tries to create a config.h file by hand for an exotic platform, not
only will it be time-consuming (the gettext-tools config.h.in for example
has more than 400 results of configure findings), but also mistakes will
show up as compilation errors. (This is the downside of the many features
gnulib has:
- C++ support,
- support for many platforms,
- using the function name 'rpl_foo' if and only if 'foo' would collide
with system-provided 'foo'.
The downside is that wrong guesses for the HAVE_* symbols lead to
compilation failures more quickly.)
Really, the approach of maintaining a config.h for a particular platform
by hand is outdated.
Even if gnulib would accommodate your wish to have a special copy of
glob.in.h that uses HAVE_FOO instead of @HAVE_FOO@, that would not solve
the problem how to maintain the config.h for specific platforms.
> On systems that aren't POSIX and don't have ready access to sed or
> similar tools
On such systems the essential step is to create the set of tools that
are needed to be able to run configure scripts. This includes a POSIX-like
shell, the coreutils, grep, sed, and maybe awk.
I would argue that porters who are "active" but have not yet achieved this
step should do this first, instead of you (and GNU) spend time on supporting
them better by adding a second or third build system to your package.
I mean, nowadays, we are running DOS inside a browser, compiling C to
JavaScript, emulating m68k on x86, and so on. The task of making the
POSIX build tools work on a non-POSIX system is much smaller and very
achievable, especially given enough time (like for VMS).
And when new OSes appear, with a roughly ANSI C compliant libc, they
typically
- either have the POSIX build tools already ported,
- or are supported as a cross-compilation target.
Bruno
