emacs-devel
[Top][All Lists]
Advanced

[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.
<http://www.gnu.org/software/gnulib/manual/html_node/Module-description.html>
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:
  http://git.savannah.gnu.org/gitweb/?p=libiconv.git;a=tree
  http://git.savannah.gnu.org/gitweb/?p=libiconv.git;a=tree;f=srclib;hb=HEAD

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

Bruno



reply via email to

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