Re: Gnulib on Windows (native / mingw32) / VMS / etc.

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden
> Date: Tue, 15 May 2018 18:31:05 -0400
> 
> 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 address@hidden@
> 
> This means I can't just define HAVE_BOOL in config.h and then use this
> header file, I need to come up with some way of emulating sed behavior
> on all my supported platforms (Windows, VMS, etc.) so I can replace
> these values.  Or else I have to create per-system instances of each of
> these files, of which I already have 5 just for alloca and getloadavg
> and if I do take on glob/fnmatch that number will balloon.

For the record: what are those 5 systems?  MS-Windows is one, but what
are the others?

> For glob.in.h in gnulib it's even worse; even the header guards require
> replacement!!
> 
>    #ifndef address@hidden@_GLOB_H
> 
> I understand that the goal is to have versions of these standard header
> files which can be used without config.h, but the GNU coding standards
> suggest that config.h must be included first in each compilation unit,
> before even system headers, so to me that desire doesn't outweigh the
> downside of using this method for non-traditional systems.
> 
> I'm interested in anyone's opinion on how best to deal with this issue.

Here's an (100% untested) idea:

  . We ignore all the Gnulib headers that work around problems in
    standard headers, such as stdbool.h, stdint.h, etc.  We assume the
    corresponding system headers are "good enough".  Where that
    happens to be false, we will add the necessary stuff to the
    config.h templates.

  . For the other Gnulib headers and for config.h, we run the
    configure script once, after importing those Gnulib headers, on
    systems where the tools for that are available, be that a
    cross-compiling environment or a native one.  (I can volunteer to
    do that for MS-Windows' MinGW port.)  This only matters for Gnulib
    headers that are processed at configure time; AFAICT, only glob.h
    and fnmatch.h need that, since all the other Gnulib headers are
    provided ready to be used, i.e. not as *.in.h templates.

  . We then keep the produced config.h and other generated Gnulib
    headers in the Make repository, for each affected system, in the
    same way we did with config.h templates until now.

  . The C sources of glob.c and fnmatch.c we import from Gnulib and
    try not to make local changes, so that these sources will not need
    any manual maintenance outside of the Gnulib project.

This idea assumes that glob.in.h and fnmatch.in.h will not change
significantly with time.  Whenever they do change, we will need to
update the templates; hopefully the changes will be minor and we will
be able to do that manually, without resorting to the full configure
run.

WDYT?