bug-gnulib
[Top][All Lists]
Advanced

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

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


From: Paul Smith
Subject: Gnulib on Windows (native / mingw32) / VMS / etc.
Date: Wed, 11 Apr 2018 14:08:17 -0400

Hi all.  I spent a bit of time this weekend looking into what it would
take to update GNU make to use the glob/fnmatch implementations from
the current gnulib, rather than the ancient (and buggy) implementation
that GNU make has embedded, more or less unchanged, for at least 25
years.

This, unfortunately, turns out to be quite a daunting task.

Gnulib glob/fnmatch rely on a huge number of other gnulib packages so
instead of the simple two-file implementation GNU make has now it
expands to a lib directory containing 20+ files (I didn't actually
count but it's quite a lot).

This matters for a few reasons: first, GNU make provides a
bootstrapping script that will let you compile make on systems which
don't already have make... that means that I need to be able to build
all these extra files without the assistance of automake (I do run
configure).  I'm not sure how easy that will be.

More worrying, GNU make is compile-able on Windows and does not require
Cygwin: it can be built using native MSVC and/or MingW32.  For
bootstrapping GNU make provides a "build_w32.bat" file that compiles
make using either gcc or MSVC.  In this setup I have a hard-coded
config.h for Windows that I install since I don't run configure. 
Making this work with the many packages added to lib seems complex.

Finally, GNU make can also be compiled on other less common
architectures, such as VMS and these ports are quite active.  Is there
any information about all these different glob/fnmatch requirements in
gnulib, insofar as portability to other environments like VMS?

I would really like to use native gnulib implementations but the
overhead involved has me considering whether it would be feasible to
try to extract the latest implementation and somehow fencing it in to
avoid all these extra dependencies.

Any comments anyone has would be welcome, cheers!



reply via email to

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