[Top][All Lists]

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

Re: convert regex.c, strftime.c mktime.c to standard C

From: Bruno Haible
Subject: Re: convert regex.c, strftime.c mktime.c to standard C
Date: Sun, 21 Nov 2010 01:37:19 +0100
User-agent: KMail/1.9.9

Eli Zaretskii wrote:
> What I meant is that the only documented way of building modules from
> gnulib is through gnulib-tool, which is a Unix shell script.  What
> exactly it does is not explained anywhere in a way that could be used
> to manually collect the module's dependencies, nor did I find an
> easily accessible information about how to do that without
> gnulib-tool.

In theory, you could do everything by hand, by looking at the fields
of the module description of every module.
But it gets very tedious, and moreover, every small mistake that you make
in this process likely becomes a portability problem that you discover
only after you've rolled your release tarball. Paul Eggert maintained
coreutils a while like this, then switched over to using gnulib-tool.
I did the same in gettext. Sam Steingold in clisp. It's just not
recommendable to do it by hand.

> In this thread, we are talking about replacing 3 modules in Emacs with
> their newer versions.  These modules constitute 5 files in the Emacs
> source tree, and have a few tests for them in configure.in.  Ideally,
> the job of replacing them would mean:
>   . replace the files with their new versions
>   . add additional files that these 5 depend on, if any; modify
>     src/Makefile.in as needed
>   . maybe add some tests to configure.in
>   . figure out what is needed for non-Posix platforms
>   . test on supported platforms

I can only recommend: Don't do it by hand. Use gnulib-tool, or don't
do it at all.

> Then there's the Makefile.am stuff; Emacs doesn't use that.

It is possible to use a Makefile.am in a subdirectory of a package
that otherwise only uses Makefile.in. An example of this package layout
is GNU libiconv:

> It's probably okay to run all this on several Unix platforms (I only
> tried on GNU/Linux, so I wouldn't know), but the task of figuring out
> this on Windows is daunting

The use of a build environment that is not capable of executing 'configure'
scripts is indeed an impediment; see my other mail about this.

> > Several packages that rely on gnulib have build instructions for mingw.
> > Such as this one:
> > <http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=README.woe32;hb=HEAD>
> Which says to install Cygwin.  No, thanks.  We don't want to ask
> Windows users to do that, just to build Emacs with MinGW.

You have to be aware of the tradeoff: Insisting on a Windows build environment
that cannot execute 'configure' scripts is an impediment to the use of Automake,
Gnulib, Libtool, and thus a penalty for the project as a whole. I can't decide
for the Emacs developers community, but for libiconv, gettext, and libunistring
I decided that making good use of Automake and Gnulib was more important than
details of build instructions for Windows binaries.


reply via email to

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