[Top][All Lists]

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

Re: MinGW "pwd -W" configure.ac correction

From: Eli Zaretskii
Subject: Re: MinGW "pwd -W" configure.ac correction
Date: Thu, 24 Oct 2013 19:25:52 +0300

> From: Glenn Morris <address@hidden>
> cc: address@hidden
> Date: Wed, 23 Oct 2013 19:12:44 -0400
> I think that (thanks to me) there's an issue with the
>   test "$MSYSTEM" = "MINGW32" && abs_srcdir=`(cd "$abs_srcdir"; pwd -W | sed 
> -e 's,^\([[A-Za-z]]\):,/\1,')`
> stuff in configure.
> Unlike $srcdir (which this used to use), it seems that $abs_srcdir it
> not set at this stage in configure. Instead it only gets set by
> config.status (IIUC).
> Does this `pwd -W' correction only matter for epaths.h?
> If so, could it be moved to the epaths-force-w32 rule in Makefile.in?

This could maybe work today, but it's a time bomb: the underlying
problem, explained in configure.ac, will bite us if we ever invoke any
MinGW program (including, but not limited to, Emacs) during the build.
So it is best to get that problem out of our way as soon as possible.

> That rule already does some correcting of paths.

Those are different problems.

> Or does every instance of $abs_srcdir in all the Makefiles need correcting?

We cannot allow something like /usr/foo/bar in $abs_srcdir, anywhere.
It must be in the /x/foo/bar format, i.e. it must include the Windows
drive letter (in the "/x/" form) explicitly.  It's just that epaths.h
were the first place where this problem hit us.

> If so, we'll have a find way to make config.status do it

How can we be sure that the same problem won't happen while the
configure script itself runs, before it invokes config.status?

reply via email to

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