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

Paul Eggert wrote: > If you can't assume 'sed', you can compile and run > a simple program that does the "@" replacement. Yes, given that the uses of 'sed' in gnulib are nearly all of the form sed -e 's/@VAR1@/VALUE1/g' ... -e 's/@VARn@/VALUEn/g' FILE you could write a program 'atsubst' such

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

> From: Paul Smith > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org > Date: Wed, 16 May 2018 12:53:22 -0400 > > On Wed, 2018-05-16 at 19:33 +0300, Eli Zaretskii wrote: > > > these values. Or else I have to create per-system instances of > > > each of these files, of which I already

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

Eli Zaretskii wrote: > Here's an (100% untested) idea: > ... > 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

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

Eli Zaretskii wrote: > > 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

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

On Wed, 2018-05-16 at 19:33 +0300, Eli Zaretskii wrote: > > 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

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

> From: Paul Smith > Cc: bug-gnulib@gnu.org > 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

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

Hi Paul, > > You really want to reduce the number of redundant Makefiles you have > > to maintain to 1, as soon as possible. > > The only makefiles the GNU make distribution will support will be > standard make makefiles. The model is: > > If you have a configure-capable system, use autotools

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

> From: Bruno Haible > Cc: Eli Zaretskii , Paul Eggert > Date: Wed, 16 May 2018 12:03:44 +0200 > > I think you are barking up the wrong tree. I'm not sure. Make is not like any other GNU package, because it is one of the basic tools required

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

On 05/16/2018 05:43 AM, Paul Smith wrote: The only makefiles the GNU make distribution will support will be standard make makefiles. The model is: If you have a configure-capable system, use autotools to compile GNU make. If you don't have a configure-capable system, use the provided

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

On Wed, 2018-05-16 at 11:29 +0200, Bruno Haible wrote: > This approach with "build_w32.bat" is outdated. The modern approach is > to use the Autoconf and Automake generated configure and Makefile.in > files without modifications. > More in detail: About ca. 10 years ago, Automake started to

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

PS: I wrote > 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). The VMS people apparently actually achieved this task; the binaries of these tools are for download at

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

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

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

Paul Smith wrote in : > 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

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

On 05/15/2018 03:31 PM, Paul Smith wrote: 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 As I

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

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

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

> Cc: psm...@gnu.org, bug-gnulib@gnu.org > From: Paul Eggert > Date: Thu, 12 Apr 2018 13:18:28 -0700 > > On 04/12/2018 05:13 AM, Eli Zaretskii wrote: > > I didn't try comparing Gnulib's glob.c and fnmatch.c with what's now > > in GNU Make -- are the differences really so

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

On 04/12/2018 05:13 AM, Eli Zaretskii wrote: I didn't try comparing Gnulib's glob.c and fnmatch.c with what's now in GNU Make -- are the differences really so significant as to disallow any attempt of a simple incorporation of changes from Gnulib in just those 2 files? Certainly that sort of

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

> From: Paul Eggert > Date: Wed, 11 Apr 2018 13:22:32 -0700 > > Except for VMS, GNU Emacs is in a boat similar to GNU Make. It uses > Gnulib (but not Automake), it is buildable on MS-Windows and does not > need Cygwin, it has its own configuration batch script for

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

Except for VMS, GNU Emacs is in a boat similar to GNU Make. It uses Gnulib (but not Automake), it is buildable on MS-Windows and does not need Cygwin, it has its own configuration batch script for MS-Windows (and MS-DOS!). So I would look to Emacs for inspiration here. I'm mostly responsible

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

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,