bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Smith
Subject: Re: Gnulib on Windows (native / mingw32) / VMS / etc.
Date: Tue, 15 May 2018 18:31:05 -0400

On Fri, 2018-04-13 at 10:42 +0300, Eli Zaretskii wrote:
> > This might require changing Gnulib to make it easier to decouple its
> > glob.c and fnmatch.c from the rest of Gnulib. We've done that for
> > some of the Gnulib modules that Emacs uses, and I expect we could do
> > that for glob.c and fnmatch.c too.
> 
> I didn't realize such an option was on the table.  If that's
> possible, it is certainly a much better way forward.

As a starting position I've modified the GNU make repository to change
the "src/glob" directory to be a top-level "lib" directory, and I've
imported alloca and getloadavg modules from gnulib to replace the old
versions previously provided with GNU make.

Things mostly still work even on Windows, with one small change to
getloadavg that I'll send under separate cover.

glob/fnmatch is a different story and I'm not sure quite how to tackle
it yet.  So far I've just moved the original glob/fnmatch (old and
buggy) into lib/ to keep things working.

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 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.

Cheers!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]