all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Hannu Koivisto <azure@iki.fi>
To: emacs-devel@gnu.org
Subject: Re: A few Windows build fixes
Date: Mon, 29 Aug 2011 11:18:33 +0300	[thread overview]
Message-ID: <83r5444ome.fsf@kalahari.s2.org> (raw)
In-Reply-To: E1Qxv8T-00007f-Ru@fencepost.gnu.org

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Hannu Koivisto <azure@iki.fi>
>> Date: Mon, 29 Aug 2011 01:46:59 +0300
>> 
>> I wanted to build the latest bzr trunk version of Emacs for Windows
>> but soon realized that the makefiles and the configure process have
>> lots of problems.
>
> Only if you use Cygwin tools.  With native (MinGW/GnuWin32) tools,
> there are no known problems, AFAIK.

I haven't heard of GnuWin32; looks like something similar to msys,
which I feel is the "standard" set of tools to be used with mingw.

In any case, it's my opinion that trying to support all these
different environments with the same makefiles (assuming that
something like cmake or similar, which is able to create real
makefiles for native tools from a higher level description, is not
used) only leads to trouble.

>> +if %MAKECMD% == gmake dos2unix config.tmp config.settings
>
> This requires users to have dos2unix installed, even if they don't use
> the Cygwin tools to build Emacs.  If there's another way of doing this

I recall I tested that failure to find dos2unix doesn't stop bat
execution, but maybe I remember incorrectly.

>> --- a/nt/makefile.w32-in
>> +++ b/nt/makefile.w32-in
>
> Is there some real change here, or did you only change EOL format?  If
> the former, please show just the changes in content.

EOL format plus removal of FIXME comment (which should be shown
only if you disable showing whitespace differences in your diff
inspecting tool of choice).

>> Cygwin make doesn't like c:/foo/bar style paths at least in targets and
>> native Windows Emacs doesn't like Cygwin style /cygdrive/c/foo/bar paths.
>> Use relative paths to avoid the problem.
>
> It's true that the Cygwin build of Make doesn't support c:/foo in
> targets, but the Windows Makefiles never use such targets, except
> through $(CURDIR), which should return a Cygwin style file name with
> Cygwin Make.  So I don't really see a problem that needs to be solved
> here.  Perhaps I'm missing something; please show the actual problems
> you had with this part.

CURDIR-based paths are passed to native Emacs for load path
purposes and if they have /cygdrive/ stuff in them, Emacs doesn't
understand that.

> In any case, I'd like to find a solution for this problem that targets
> Cygwin alone, if possible.  Sprinkling quotes in 2 different styles
> all over the Makefiles is not my idea of fun, because the quoting
> issue is very fragile on Windows to begin with, especially since we
> try to support at least 3 or 4 different combinations of tools.

At first I used macros DQUOTE etc. but gave up after seeing that
normal double quotes were used in many, many places.

>> +CURDIR=.
>
> This will break "make -C", won't it?  Or at least make it fragile and
> unreliable.

Perhaps.  Is there a need to use -C when building Emacs for
Windows?  A more important need than to build Emacs under Cygwin?

>> -	- mkdir "$(INSTALLDIR)"
>> +	- mkdir -p "$(INSTALLDIR)"
>
> Please don't.  We don't want to rely on the assumption that `mkdir' is
> a GNU mkdir.exe.  This command needs also to run when the shell is
> cmd.exe, and its built-in `mkdir' doesn't support the -p switch (it
> creates intermediate directories by default).

Using cmd didn't work with mingw/msys (make SHELL=cmd.exe didn't do
anything at all) so I couldn't test that.  Not that I would have
considered supporting cmd as the shell (with GNU make makefiles,
nmake is another matter) even if it had worked.

> There are more places where you use "mkdir -p"; please find some other
> solution for that particular problem, or let's leave it unsolved, as
> no one has complained until now, AFAIR.

Well, if mkdir in cmd works like "mkdir -p", I suppose one could
simply use a macro and set it to either mkdir or mkdir -p depending
on the shell being used.

Not solving this means that "make install" won't work when cmd is
not used.

>> +INSTALL_DIR_MIXED := $(INSTALL_DIR)
>> +ifeq "$(shell cygpath $(INSTALL_DIR))" "$(INSTALL_DIR)"
>> +INSTALL_DIR_MIXED := $(shell cygpath -m "$(INSTALL_DIR)")
>> +endif
>
> I don't understand the need for this gork.  Please explain.  Is the
> Cygwin build supposed to use Cygwin `cp' etc., or their native
> versions?
>
> In any case, why do we need both INSTALL_DIR and INSTALL_DIR_MIXED?

When used in makefile rules, Cygwin style path is needed, and when
passing the path to native binaries like addpm etc that are used
during installation, a mixed style path is needed.  `cp' and
everything else is assumed to be a Cygwin version when building
under Cygwin.

> If both are needed, we will need a corresponding change in nmake.defs.

I don't think changes are needed in nmake.defs, Cygwin style paths
should not be involved there.

-- 
Hannu




  reply	other threads:[~2011-08-29  8:18 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-28 22:46 A few Windows build fixes Hannu Koivisto
2011-08-29  6:15 ` Eli Zaretskii
2011-08-29  8:18   ` Hannu Koivisto [this message]
2011-08-29 10:05     ` Eli Zaretskii
2011-08-29 12:03       ` Hannu Koivisto
2011-08-29 13:28         ` Eli Zaretskii
2011-08-29 15:55           ` Stefan Monnier
2011-08-29 16:11             ` Eli Zaretskii
2011-08-29 15:48     ` Stefan Monnier
2011-08-29 16:08       ` Eli Zaretskii
2011-08-29 19:48         ` Jan Djärv
2011-08-31  2:42       ` Vijay Lakshminarayanan
2011-08-31  6:11         ` Eli Zaretskii
2011-08-31 13:17           ` Stefan Monnier
2011-09-01 17:55             ` Vijay Lakshminarayanan
2011-09-02  0:14               ` Andy Moreton
2011-09-02  7:07                 ` Eli Zaretskii
2011-09-02 11:43                   ` Andy Moreton
2011-09-02 12:48                     ` Stefan Monnier
2011-09-02 14:14                       ` Eli Zaretskii
2011-09-02 14:18                       ` Jason Rumney
2011-09-02 14:47                         ` Stefan Monnier
2011-09-02 14:05                     ` Eli Zaretskii
2011-09-02 14:48                       ` Stefan Monnier
2011-09-02 15:48                         ` Vijay Lakshminarayanan
2011-09-02 16:47                         ` Eli Zaretskii
2011-09-06  2:49                           ` Stefan Monnier
2011-09-06  4:33                             ` Eli Zaretskii
2011-09-06 18:04                               ` Stefan Monnier
2011-09-06 18:26                                 ` Eli Zaretskii
2011-09-07  3:29                                   ` Stefan Monnier
2011-09-07  5:17                                     ` Eli Zaretskii
2011-09-07 12:50                                       ` Stefan Monnier
2011-09-07 16:48                                         ` Eli Zaretskii
2011-09-08  8:33                                   ` Hannu Koivisto
2011-09-08  8:49                                     ` Eli Zaretskii
2011-09-08  9:06                                       ` Hannu Koivisto
2011-09-02 15:50                 ` Vijay Lakshminarayanan
2011-09-02  2:48               ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83r5444ome.fsf@kalahari.s2.org \
    --to=azure@iki.fi \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.