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:14:27 +0100
User-agent: KMail/1.9.9

David De La Harpe Golden wrote:
> > Emacs uses an Autoconf configure.in.
> 
> Not on all platforms, no. e.g. w32 emacs doesn't.

When you have a single platform like this, which is not built by executing
'configure', the maintainer has to keep lists of preprocessor defines or
a prefabricated config.h up-to-date, manually. This is tedious, and this
would be the even more tedious when you start using gnulib, to the point
where it becomes no more manageable.

For libiconv and gettext, at the moment when the packages started to use
gnulib, I had to change the build instructions for the Windows port to
recommend mingw + configure (instead of dedicated config.h and Makefiles
for that platform).

> > there are 3 ways to build binaries for mingw:
> >    - using MSYS,
> >    - from Cygwin,
> >    - cross-compiling from Unix.
> 
> You don't need MSYS to build w32 binaries _with_ the mingw toolchain

Yes, but the point is to use a build environment that can execute configure
scripts.

With just a mingw-gcc, mingw-binutils, and 'make', you can build Windows
binaries, but you have to update a config.h.w32 each time something in the
autoconfiguration changes, and you have to update the Makefile.in -> Makefile
conversion facility each time a new AC_SUBSTed variable used. This
maintenance burden goes away if you use a build environment that can execute
configure scripts.

gnulib uses a *lot* of autoconfiguration, and the set of AC_SUBSTed variables
changes every week. That

> (cygwin emacs is a also different matter, that's most successfully built 
> with cygwin proper of course...)

Sure, that's a different beast. I'm talking about using Cygwin as an
environment for building mingw binaries.

> In fact, the MSYS variants of various command line tools have odd 
> handling of some things (sort of like a cut-down cygwin, but compatible 
> with neither modern cygwin nor native w32 conventions) compared to the 
> more w32-native-ised gnuwin32 tools, say.

Yes. For this reason, I'd recommend Cygwin over MSYS, as an environment
for building mingw binaries.

> . w32 emacs
>    exists
>    native w32 port
>    usually built with mingw (remember, used to build with MSVC++ too)
>    does not use autoconf

What I'm suggesting, in order to be able to use more of autoconf, automake,
and gnulib, is:

  . w32 emacs
    native w32 port
    usually built with mingw (semi-cross from Cygwin, or cross from a glibc
    system)
    uses autoconf

About MSVC++ builds: With recent (unreleased) Autoconf, the 'compile' script
can work directly with the MSVC 'cl' command. So, soon, you will also be
able to build native Windows binaries of programs with MSVC by using the
regular autoconf generated configure script.

Bruno



reply via email to

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