emacs-devel
[Top][All Lists]
Advanced

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

Re: Building Emacs from a new MinGW environment


From: Eli Zaretskii
Subject: Re: Building Emacs from a new MinGW environment
Date: Tue, 17 Sep 2013 11:30:28 +0300

> Date: Tue, 17 Sep 2013 10:17:38 +0200
> From: Dani Moncayo <address@hidden>
> Cc: Emacs development discussions <address@hidden>
> 
> > Change this:
> >
> >   case "${srcdir}" in
> >     [[\\/]]* | ?:[[\\/]]*) ;;
> >
> > into this:
> >
> >   case "${srcdir}" in
> >     [[\\/]]* | ?:[[\\/]]*)
> >     test "$MSYSTEM" = "MINGW32" && srcdir=`(cd "$srcdir"; pwd -W)`
> >     ;;
> >
> > This fix, if it works, is better, since it will fix also the stuff
> > that gets written into .gdbinit file in the build directory (it didn't
> > work for you because an MSYS file name was written there, and the
> > MinGW build of GDB doesn't grok that).
> 
> This does't work in my case, because at that point, "${srcdir}"
> contains the relative path "../emacs.git", not something like
> "/c/whatever" or "c:/whatever".

OK, then we could put this line

  test "$MSYSTEM" = "MINGW32" && srcdir=`(cd "$srcdir"; pwd -W)`

immediately below the 'esac' in the fragment I've shown.  Does that do
the job for you?

> I think that the right fix is to replace *all* the treatment of
> patterns like the above ("/c/whatever" or "c:/whatever") with logic
> based on the "pwd -W" feature of MSYS.
> 
> IOW, an MSYS path doesn't have to match none of the above patterns, so
> the only reliable way of getting a Windows-native path is with "pwd
> -W".
> 
> Therefore, things line "msys_to_w32", "msys_lisppath_to_w32" should be
> replaced with the above criteria.

I'm not sure I understand what you are suggesting, specifically.  Can
you show a patch that works for you?

In any case, the problem with src/.gdbinit in the build tree still
needs to be solved; no amount of changes in the Makefile's can do
that, because that file is created by config.status.  So we still need
something in configure.ac as well.

The advantage of my suggestion is that it solves this problem in a
single place, once and for all, while what you seem to suggest would
need multiple changes in many places.  Why is that better?



reply via email to

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