Building Emacs on Windows with MinGW+MSYS (was: Emacs pretest 24.0.90)

Building Emacs on Windows with MinGW+MSYS (was: Emacs pretest 24.0.90)

[Dani Moncayo]

>> If it is possible, I'd like to know the exact steps involved in such
>> weekly builds (in order to learn and try to reproduce them in my
>> system).
>
> nt/INSTALL should have all required information. If not, please file a
> bug detailing what is missing.

While reading that file, I've tried something that it suggests: to use
"mingw32-make" as the make tool.  To my delight, it worked flawlessly!

So, it's possible to build Emacs on Windows using _exclusively_ the
utilities provided by MinGW, with its MSYS package included (it
supplies necessary utilities like rm or cp).

Thus, I suggest an update of the file nt/INSTALL. In particular, the
last sentence of this paragraph:

  MSYS sh.exe also appears to cause
  various problems, e.g., it is known to cause failures in commands
  like "cmd /c FOO" in the Makefiles, because it thinks "/c" is a
  Unix-style file name that needs conversion to the Windows format.
  If you have MSYS installed, try "make SHELL=cmd.exe" to force the
  use of cmd.exe instead of the MSYS sh.exe.

The solution proposed there doesn't seem to work (at least for me).  I
would change it for another one that suggested using "mingw32-make"
instead of "make".

----------------

And finally, here is and updated version of my recipe to build Emacs on Windows:

0. Prerequisites:
0.1. Install bzr (if you are going to pull the sources from a bzr branch).
0.2. Install MinGW (with the MSYS package).
0.3. Create a file "mingw-console.cmd" with the content described in [a].

1. Get the sources you want to build from ("bzr pull" or your favorite way).
2. Invoke the "mingw-console.cmd" script (to open a console where
we'll run the following commands).
3. run "cd C:\emacs\trunk\nt". [b].
4. run "configure --without-xpm --without-png --without-jpeg
--without-tiff --without-gif".
5. run "mingw32-make bootstrap".
6. run "mingw32-make info".
7. run "mingw32-make install".

That's all, folks!


--- Footnotes: ---

[a] File "mingw-console.cmd":
------ begin of file -----------------------------
@set PATHMINGW=C:\MinGW\bin;C:\MinGW\msys\1.0\bin
@set PATHBAZAAR=C:\Program Files (x86)\Bazaar
@set PATH=%PATHMINGW%;%PATHBAZAAR%;%PATH%
@cmd
------ end of file -------------------------------
Substitute:
* "C:\MinGW" with the directory where you've installed mingw(+msys).
* "C:\Program Files (x86)\Bazaar" with the directory where you've
installed bazaar.

[b] Substitute "C:\emacs\trunk" with the directory where you've got
the emacs source tree.


-- 
Dani Moncayo

Re: Building Emacs on Windows with MinGW+MSYS (was: Emacs pretest 24.0.90)

[Eli Zaretskii]

> Date: Thu, 13 Oct 2011 23:01:22 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: emacs-devel@gnu.org, Eli Zaretskii <eliz@gnu.org>
> 
> While reading that file, I've tried something that it suggests: to use
> "mingw32-make" as the make tool.  To my delight, it worked flawlessly!
> 
> So, it's possible to build Emacs on Windows using _exclusively_ the
> utilities provided by MinGW, with its MSYS package included (it
> supplies necessary utilities like rm or cp).

If you use the MinGW Make, then the only tools you need from MSYS are
cp, mv, and rm.  It makes no sense to install MSYS for these 3
programs.  Just install the GnuWin32 Coreutils, and be done.

> Thus, I suggest an update of the file nt/INSTALL. In particular, the
> last sentence of this paragraph:
> 
>   MSYS sh.exe also appears to cause
>   various problems, e.g., it is known to cause failures in commands
>   like "cmd /c FOO" in the Makefiles, because it thinks "/c" is a
>   Unix-style file name that needs conversion to the Windows format.
>   If you have MSYS installed, try "make SHELL=cmd.exe" to force the
>   use of cmd.exe instead of the MSYS sh.exe.
> 
> The solution proposed there doesn't seem to work (at least for me).

Probably because you tried it with MSYS Make.  That solution will only
work with the MinGW Make.

> And finally, here is and updated version of my recipe to build Emacs on Windows:

Sorry, but I see no need to recommend MSYS just to have 3 programs.
MSYS is tricky to install if you already have a native MinGW
development environment, because you need to keep them separate (due
to incompatible features), but still let MSYS invoke MinGW programs,
such as the compiler and the linker.  Setting this up is not for a
casual user.  Downloading a single GnuWin32 package is much simpler.

Re: Building Emacs on Windows with MinGW+MSYS (was: Emacs pretest 24.0.90)

[Dani Moncayo]

> If you use the MinGW Make, then the only tools you need from MSYS are
> cp, mv, and rm.  It makes no sense to install MSYS for these 3
> programs.  Just install the GnuWin32 Coreutils, and be done.

In my case, it make sense, because MSYS gives me a useful set of tools
beyond those three: diff, grep, find, touch, cat, ls and many more.


>> And finally, here is and updated version of my recipe to build Emacs on Windows:
>
> Sorry, but I see no need to recommend MSYS just to have 3 programs.
> MSYS is tricky to install if you already have a native MinGW
> development environment, because you need to keep them separate (due
> to incompatible features), but still let MSYS invoke MinGW programs,
> such as the compiler and the linker.  Setting this up is not for a
> casual user.  Downloading a single GnuWin32 package is much simpler.

I've talking about the msys package that is part of MinGW.  It is
trivial to install together with MinGW, because, as I say, is part of
it (it's a package):

  C:\>mingw-get list msys

  Package: msys-base                                       Subsystem: msys
  Components: bin

  A Basic MSYS Installation (meta)
  --------------------------------

  This meta package contains the components necessary to create  a  basic,
  small,  but  relatively  useful  MSYS installation. It includes the core
  system, bash, various command line utilities, and  archiving/compression
  tools.  It  attempts  to replicate, with certain judicious additions and
  deletions, the set  of  tools  originally  installed  by  the  old  MSYS
  monolithic installers.

I found it very handy, not only for building Emacs, but to have a
"minimal system" for programming.

-- 
Dani Moncayo

Re: Building Emacs on Windows with MinGW+MSYS

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> Downloading a single GnuWin32 package is much simpler.

Is gnuwin{32,64} generally the recommended way of getting unixy
utilities on windows these days...?

[I don't have a windows machine usually, but I did download the win8
demo, which I can run in a VM, and was thinking of trying to use it for
porting some stuff to windows...]

-miles

-- 
"Suppose we've chosen the wrong god. Every time we go to church we're
just making him madder and madder." -- Homer Simpson

Multi-platform build system (was: Building Emacs on Windows with MinGW+MSYS)

[Óscar Fuentes]

[snip]

Time ago I volunteered to write a CMake [1] build spec for Emacs. It was
considered unnecessary by the people who does most of the work on the
current build systems. I will have some free time (sigh) on the next
months, so I reiterate the offer in case anyone changed his mind.

[1]: www.cmake.org

Re: Multi-platform build system

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> Time ago I volunteered to write a CMake [1] build spec for Emacs. It
> was considered unnecessary by the people who does most of the work
> on the current build systems. I will have some free time (sigh) on
> the next months, so I reiterate the offer in case anyone changed his
> mind.

If this were in the repo, would it become a maintenance burden once
you don't have time to do so yourself?  Obviously the Emacs build
process is relatively complex, so presumably maintenance would require
more than updating lists of files occasionally.

Of course, maybe it would be _less_ of a burden than maintaining the
current scripts etc... (presuming the additional dependency on cmake
is acceptable)

-miles

-- 
Quotation, n. The act of repeating erroneously the words of another. The words
erroneously repeated.

Re: Multi-platform build system

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>> Time ago I volunteered to write a CMake [1] build spec for Emacs. It
>> was considered unnecessary by the people who does most of the work
>> on the current build systems. I will have some free time (sigh) on
>> the next months, so I reiterate the offer in case anyone changed his
>> mind.
>
> If this were in the repo, would it become a maintenance burden once
> you don't have time to do so yourself?  Obviously the Emacs build
> process is relatively complex, so presumably maintenance would require
> more than updating lists of files occasionally.
>
> Of course, maybe it would be _less_ of a burden than maintaining the
> current scripts etc...

Experience shows that a cmake spec usually is a fraction of the length
of the equivalent autoconf+automake/Makefile spec,
line-wise. Maintenance work is proportionally reduced. It's easier to
add new features, too.

> (presuming the additional dependency on cmake is acceptable)

Yep, that was the inconvenience that people voiced the last time. The
cmake build would work everywhere as long as cmake is present but now,
like then, I'm thinking mostly on the Windows users, who already have to
install other software besides the compiler for building Emacs. You'll
remove the GnuWin32 dependency and replace it with cmake. The gain is,
precisely, on the simplification of maintenance and the added value of
the multiple features cmake offers [1]. The people who maintains the
Windows scripts said that maintaining those is no problem, so my
proposal was dumped.

[1]: http://www.vtk.org/Wiki/Really_Cool_CMake_Features (that's not a
complete list)

Re: Multi-platform build system (was: Building Emacs on Windows with MinGW+MSYS)

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> [snip]
>
> Time ago I volunteered to write a CMake [1] build spec for Emacs. It was
> considered unnecessary by the people who does most of the work on the
> current build systems. I will have some free time (sigh) on the next
> months, so I reiterate the offer in case anyone changed his mind.

The current build system works, it's complex mostly because of what
emacs needs (dumping is a big factor).  We are using the standard GNU
tools, and there's a lot of collective experience dealing with those
tools. 
Whatfor emacs 's the advantage of yet another build system that has not yet 
What is the advantage for emacs of yet another build system that has not
been widely adopted by GNU projects? 

Re: Multi-platform build system

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> Experience shows that a cmake spec usually is a fraction of the
> length of the equivalent autoconf+automake/Makefile spec,
> line-wise. Maintenance work is proportionally reduced. It's easier
> to add new features, too.

Off-topic, but I'm quite skeptical of this claim, compared to
automake.  Makefile.am files tend to be pretty darn close to the
minimal amount of information required to build (in typical cases: a
list of source files), and very easy to extend.

Automake's implementation is not very pretty, but the interface
presented to the user is extremely good.

-Miles

-- 
Cannon, n. An instrument employed in the rectification of national boundaries.

Re: Multi-platform build system (was: Building Emacs on Windows with MinGW+MSYS)

[Juanma Barranquero]

> Time ago I volunteered to write a CMake [1] build spec for Emacs. It was
> considered unnecessary by the people who does most of the work on the
> current build systems.

IIRC, it was also unacceptable, because the user would need CMake to
build Emacs, as opposed to just generating makefiles than can be
packed into the tarball. Is that so, or am I misremembering?

    Juanma

Re: Multi-platform build system (was: Building Emacs on Windows with MinGW+MSYS)

[Christoph Scholtes]

On 10/13/2011 7:06 PM, Juanma Barranquero wrote:
>> Time ago I volunteered to write a CMake [1] build spec for Emacs. It was
>> considered unnecessary by the people who does most of the work on the
>> current build systems.
>
> IIRC, it was also unacceptable, because the user would need CMake to
> build Emacs, as opposed to just generating makefiles than can be
> packed into the tarball. Is that so, or am I misremembering?

Couldn't you pack the Makefiles generated with CMake into the tarball 
when you create it?

Re: Multi-platform build system (was: Building Emacs on Windows with MinGW+MSYS)

[Juanma Barranquero]

On Fri, Oct 14, 2011 at 03:18, Christoph Scholtes
<cschol2112@googlemail.com> wrote:

> Couldn't you pack the Makefiles generated with CMake into the tarball when
> you create it?

IIRC, the makefiles contain absolute paths to the tools (compiler, etc.).

    Juanma

Re: Multi-platform build system

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>> Experience shows that a cmake spec usually is a fraction of the
>> length of the equivalent autoconf+automake/Makefile spec,
>> line-wise. Maintenance work is proportionally reduced. It's easier
>> to add new features, too.
>
> Off-topic, but I'm quite skeptical of this claim, compared to
> automake.  Makefile.am files tend to be pretty darn close to the
> minimal amount of information required to build (in typical cases: a
> list of source files), and very easy to extend.
>
> Automake's implementation is not very pretty, but the interface
> presented to the user is extremely good.

Well, automake scripts can be easy once you know how to handle them, but
auto* seems hard to learn.

My first experience with a big and complex project was LLVM
(www.llvm.org) What they have now is half as complex as the system I
wrote because they removed features (because of changing trade-off). It
took me a few weekends to write (keep in mind that I was a total
beginner with cmake) being the main time-consuming factor the large
amount of time each test build required. Since, people who had no
previous experience with autoconf/make nor with cmake claim to be more
at easy with the cmake build.

All of this is very subjective, of course. The Emacs build is not your
typical C/C++ project, which cmake is optimized for, but neither it is
LLVM, and it worked very well.

Re: Multi-platform build system

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

>> Time ago I volunteered to write a CMake [1] build spec for Emacs. It was
>> considered unnecessary by the people who does most of the work on the
>> current build systems.
>
> IIRC, it was also unacceptable, because the user would need CMake to
> build Emacs, as opposed to just generating makefiles than can be
> packed into the tarball. Is that so, or am I misremembering?

You are correct about the makefiles. You need cmake to generate
them. But today you need some external tools (I'm talking about Windows)
that would be unnecessary with cmake. So I can't see why requiring cmake
instead of those Unix utils is unacceptable.

Re: Multi-platform build system

[Óscar Fuentes]

Dan Nicolaescu <dann@gnu.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> [snip]
>>
>> Time ago I volunteered to write a CMake [1] build spec for Emacs. It was
>> considered unnecessary by the people who does most of the work on the
>> current build systems. I will have some free time (sigh) on the next
>> months, so I reiterate the offer in case anyone changed his mind.
>
> The current build system works, it's complex mostly because of what
> emacs needs (dumping is a big factor).  We are using the standard GNU
> tools, and there's a lot of collective experience dealing with those
> tools. 
>
> What is the advantage for emacs of yet another build system that has not
> been widely adopted by GNU projects? 

As someone who builds Emacs on Windows, cmake would make possible to
remove gnuwin32 from my machines. From the POV of the developers,
extending the cmake scripts is much easier than fighting with .BAT
files, differences across Windows versions, etc.

Please keep in mind that I'm not pushing for a cmake build. I'm just
offering it, in case you guys are interested.

Re: Multi-platform build system

[Juanma Barranquero]

On Fri, Oct 14, 2011 at 03:33, Óscar Fuentes <ofv@wanadoo.es> wrote:

> You are correct about the makefiles. You need cmake to generate
> them. But today you need some external tools (I'm talking about Windows)
> that would be unnecessary with cmake.

You would still need to install some unix tools to build the info
files, I think?

> So I can't see why requiring cmake
> instead of those Unix utils is unacceptable.

I suppose, the less common the tools are, the greater the resistance.
For many people (at least, people building Unixy tools, like Emacs, on
Windows), installing rm, cp etc. is not a prerequisite because they
will likely have them already installed.

    Juanma

Re: Multi-platform build system

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

>> Couldn't you pack the Makefiles generated with CMake into the tarball when
>> you create it?
>
> IIRC, the makefiles contain absolute paths to the tools (compiler, etc.).

Right. CMake does the job of the configure scripts and generate
makefiles (or project files for several IDEs) which are fully
configured, with paths, user options, available libraries, etc. Those
makefiles are hardly usable outside of the machine were they were
created, as it is the case with the makefiles generated by the
`configure' script.

Re: Multi-platform build system

[Miles Bader]

Juanma Barranquero <lekktu@gmail.com> writes:
>> Time ago I volunteered to write a CMake [1] build spec for Emacs. It was
>> considered unnecessary by the people who does most of the work on the
>> current build systems.
>
> IIRC, it was also unacceptable, because the user would need CMake to
> build Emacs, as opposed to just generating makefiles than can be
> packed into the tarball. Is that so, or am I misremembering?

That is so ... cmake, like most build-systems, requires itself to be
installed for the builder, not just the packager; the autotools are
fairly unique in _not_ requiring this [though I have seen some other
systems that kinda do it].

[Another somewhat rare property of autoconf is the emphasis on
feature-_testing_ instead of version/system-name-driven configuration;
this may be less useful on windows, which seems to have a smaller
amount of variability, but of course it's invaluable on unixy
systems...]

-Miles

-- 
Joy, n. An emotion variously excited, but in its highest degree arising from
the contemplation of grief in another.

Re: Multi-platform build system

[Juanma Barranquero]

On Fri, Oct 14, 2011 at 03:57, Miles Bader <miles@gnu.org> wrote:

> That is so ... cmake, like most build-systems, requires itself to be
> installed for the builder, not just the packager

But it can generate makefiles. If it trusted the user to have the
compiler, etc. in the PATH, instead of hardcoding their paths, it
could be used like the autotools.

> but of course it's invaluable on unixy systems...]

Of course. I still remember the fist time I compiled Perl on a Unix
system, back in 1991. It used a tool similar to autoconf, and it did
make funny comments when it was unable to find some libraries or it
disliked your platform choice or the like. Very LarryWallesque.

    Juanma

Re: Multi-platform build system

[Miles Bader]

Juanma Barranquero <lekktu@gmail.com> writes:
>> but of course it's invaluable on unixy systems...]
>
> Of course. I still remember the fist time I compiled Perl on a Unix
> system, back in 1991. It used a tool similar to autoconf, and it did
> make funny comments when it was unable to find some libraries or it
> disliked your platform choice or the like. Very LarryWallesque.

Yeah I remember that well ... man those "funny" comments got on my
nerves after a while!!!

[The perl configuration system was also a little different, in that it
was not only really chatty, but also quite interactive, meaning you
had to sit there and answer questions (later I think an unattended
mode was added, but I'm not sure this completely eliminated
interaction) ... what stuff it did do automatically, tended to work
more by "examination" (grep /usr/include for XXX) than by actual
testing (run the compiler with an input program trying to use XXX).

Autoconf was no doubt inspired in part by perl's configure, but the
hands-free operation and real testing were a major advance over it,
from a user's point of view...]

-Miles

-- 
Cabbage, n. A familiar kitchen-garden vegetable about as large and wise as a
man's head.

Re: Multi-platform build system

[Juanma Barranquero]

> Yeah I remember that well ... man those "funny" comments got on my
> nerves after a while!!!

Yes, after the first three or four times they weren't funny anymore ;-)

> [The perl configuration system was also a little different, in that it
> was not only really chatty, but also quite interactive, meaning you
> had to sit there and answer questions

You're right, though I didn't remember that until you mentioned it
(it's been a long time).

> Autoconf was no doubt inspired in part by perl's configure, but the
> hands-free operation and real testing were a major advance over it,
> from a user's point of view...]

Not to mention the generality. Perl's system was one-of-a-kind.

    Juanma

Re: Multi-platform build system

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Oct 14, 2011 at 03:33, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> You are correct about the makefiles. You need cmake to generate
>> them. But today you need some external tools (I'm talking about Windows)
>> that would be unnecessary with cmake.
>
> You would still need to install some unix tools to build the info
> files, I think?

texinfo, yes. I'm using what comes with MikTex. IIRC gnuwin32 lacked it
or didn't work for me.

>> So I can't see why requiring cmake
>> instead of those Unix utils is unacceptable.
>
> I suppose, the less common the tools are, the greater the resistance.
> For many people (at least, people building Unixy tools, like Emacs, on
> Windows), installing rm, cp etc. is not a prerequisite because they
> will likely have them already installed.

It's obvious that the people who currently build Emacs already have
those tools installed, and it is very probable that cmake is absent. So
the new system would bring no advantage for them unlike they (like me)
would like to remove those Unixy tools from the system.

Re: Multi-platform build system

[Juanma Barranquero]

On Fri, Oct 14, 2011 at 04:52, Óscar Fuentes <ofv@wanadoo.es> wrote:

> texinfo, yes. I'm using what comes with MikTex. IIRC gnuwin32 lacked it
> or didn't work for me.

According to Dani Moncayo, with MSYS you can have both the file tools
(cp, etc) and the info ones. So it's just one install.

> It's obvious that the people who currently build Emacs already have
> those tools installed

I was talking about people who builds packages other than Emacs. I
wonder if there's many people who builds Emacs on Windows (not many, I
think) and do not build other unix packages (still less).

    Juanma

Re: Multi-platform build system

[Stephen J. Turnbull]

Miles Bader writes:

 > [Another somewhat rare property of autoconf is the emphasis on
 > feature-_testing_ instead of version/system-name-driven configuration;
 > this may be less useful on windows, which seems to have a smaller
 > amount of variability, but of course it's invaluable on unixy
 > systems...]

XEmacs's experience is to some degree the opposite, especially for
those users who can't do any configuration themselves.  Specifically,
as we have a lot of optional features which require libraries that are
non-standard on Windows (Windows provides the functionality in
proprietary libraries with different APIs in most cases), but are
typically provided by free OSes.  So on Debian you'll just have libpng
or zlib, but on Windows you typically need to install them or have the
configuration script tell the makefiles not to link them.

It's true that core APIs like the exact definition of a time_t or
whether SIGIO is broken vary less on Windows, but it's always been a
PITA that autoconf only works for Cygwin builds on Windows from the
point of view of adding new bells and whistles, because for native
builds people's config.inc include file for config.bat often breaks
and they have to edit them by hand.

Re: Multi-platform build system

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Dan Nicolaescu <dann@gnu.org> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> [snip]
>>>
>>> Time ago I volunteered to write a CMake [1] build spec for Emacs. It was
>>> considered unnecessary by the people who does most of the work on the
>>> current build systems. I will have some free time (sigh) on the next
>>> months, so I reiterate the offer in case anyone changed his mind.
>>
>> The current build system works, it's complex mostly because of what
>> emacs needs (dumping is a big factor).  We are using the standard GNU
>> tools, and there's a lot of collective experience dealing with those
>> tools. 
>>
>> What is the advantage for emacs of yet another build system that has not
>> been widely adopted by GNU projects? 
>
> As someone who builds Emacs on Windows, cmake would make possible to
> remove gnuwin32 from my machines. From the POV of the developers,
> extending the cmake scripts is much easier than fighting with .BAT
> files, differences across Windows versions, etc.

The majority of emacs developers don't do Windows builds, adding another
build systems would affect the majority of developers, so this does not
seem to be very useful...

Re: Building Emacs on Windows with MinGW+MSYS

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Dani Moncayo <dmoncayo@gmail.com>,  lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 14 Oct 2011 08:09:52 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > Downloading a single GnuWin32 package is much simpler.
> 
> Is gnuwin{32,64} generally the recommended way of getting unixy
> utilities on windows these days...?

If you really want something very similar to Unix, you will be better
off with Cygwin.

GnuWin32 is the recommended way of having Unixy utilities if you want
compatibility with other native w32 programs.  Cygwin is subtly
incompatible.

> [I don't have a windows machine usually, but I did download the win8
> demo, which I can run in a VM, and was thinking of trying to use it for
> porting some stuff to windows...]

If you get Cygwin, you will find out that most stuff is already ported
there.

Re: Building Emacs on Windows with MinGW+MSYS (was: Emacs pretest 24.0.90)

[Eli Zaretskii]

> Date: Fri, 14 Oct 2011 00:23:43 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: lekktu@gmail.com, emacs-devel@gnu.org
> 
> > If you use the MinGW Make, then the only tools you need from MSYS are
> > cp, mv, and rm.  It makes no sense to install MSYS for these 3
> > programs.  Just install the GnuWin32 Coreutils, and be done.
> 
> In my case, it make sense, because MSYS gives me a useful set of tools
> beyond those three: diff, grep, find, touch, cat, ls and many more.

If you use those outside of Emacs, then this benefit is unrelated to
the issue at hand, which is what should be the best recommended way of
building Emacs on Windows.

If you use them from Emacs, then the same caveats apply about
file-name conversion done by MSYS tools.  The MSYS developers
themselves explicitly tell that these tools are not supposed to be
used for any purpose _except_ running the Posix configure scripts and
the Makefile's produced by those scripts, for the explicit goal of
building MinGW packages.  "Building", not "using".  So beware.

> I found it very handy, not only for building Emacs, but to have a
> "minimal system" for programming.

You are using MSYS out of its intended purpose, so it will bite you
some day.

Re: Multi-platform build system

[Stefan Monnier]

> Time ago I volunteered to write a CMake [1] build spec for Emacs.  It was
> considered unnecessary by the people who does most of the work on the
> current build systems. I will have some free time (sigh) on the next
> months, so I reiterate the offer in case anyone changed his mind.

I'm not sure I understand the way the discussion is going (at least from
a rational point of view ;-).  So I'll start over from the beginning.

Currently Emacs has 2 build systems: one that is a mix of old-style
ad-hoc config files (predefined per system in src/m and src/s) and
autoconf+make, and another one for Windows builds.

We could use CMake to replace either (or both) of them:
- I don't think only replacing the Windows build systems would be
  a great improvement.
- Getting rid of the duplication between the two build systems would be nice.
- I don't know what would be the benefit of replacing the autoconf
  system: I'd be very happy to get rid of the src/m and src/s config
  files (we've already made significant progress in this direction) but
  I don't think using CMake would magically do that for us.  And it
  would add `cmake' as an additional build-dependency (compared to
  autoconf which is not absolutely needed to build Emacs).

I have no experience with CMake, so it's hard to know whether it would
be a good change or not.  But I would be interested to see what that
would look like.


        Stefan