GNU bug report logs - #15675
building in directory with spaces in name

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15675 in the body.
You can then email your comments to 15675 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: “Adrian” <silvibus <at> autistici.com>
To: bug-gnu-emacs <at> gnu.org
Subject: the configure script invoked before make
Date: Mon, 21 Oct 2013 19:02:57 +0200

Downloaded and put the emacs24.3 sources in a directory whose name contained
1 space. The configure script seemed not able to interpret the directory
name properly, as it could only grasp the word preceeding the space in the 
directory name. I verified that this was the problem, as i changed the directory
name to contain no spaces and the configure script ran beautifully.

Message #20 received at 15675-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 15675-done <at> debbugs.gnu.org
Subject: Re: bug#15675: the configure script invoked before make
Date: Wed, 23 Oct 2013 02:26:27 -0400

Version: 24.4

“Adrian” wrote:

> Downloaded and put the emacs24.3 sources in a directory whose name
> contained 1 space. The configure script seemed not able to interpret
> the directory name properly, as it could only grasp the word
> preceeding the space in the directory name. I verified that this was
> the problem, as i changed the directory name to contain no spaces and
> the configure script ran beautifully.

In Emacs trunk, building in directories whose name contains space should
now work. (Installing into such a directory probably still doesn't work.)

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#15675: the configure script invoked before make
Date: Thu, 24 Oct 2013 02:12:17 +0100

On Wed 23 Oct 2013, Glenn Morris wrote:

> Version: 24.4
>
> “Adrian” wrote:
>
>> Downloaded and put the emacs24.3 sources in a directory whose name
>> contained 1 space. The configure script seemed not able to interpret
>> the directory name properly, as it could only grasp the word
>> preceeding the space in the directory name. I verified that this was
>> the problem, as i changed the directory name to contain no spaces and
>> the configure script ran beautifully.
>
> In Emacs trunk, building in directories whose name contains space should
> now work. (Installing into such a directory probably still doesn't work.)

The changes to support this break doing an out of tree build using
MSYS/MinGW.

I have been trying to build from bzr r114764, with the source tree at
"c:\emacs\src\emacs\trunk", and building in an "obj-mingw32" subdir.

Building in "obj-mingw32/lib" fails because CPP and CPPFLAGS still have
"-I ../nt/inc", which should either be "-I ../../nt/inc" (relative to
"obj-mingw32") or be absolute.

My attempts to patch configure.ac to fix this resulted in a configure
script which complained about missing ACl libraries (which is normally
handled by trunk/nt/mingw-config.site).

As I am inexpert in autotools, I instead tried to work around this by
adding the absolute path to "trunk/nt/inc" to CPPFLAGS on the configure
command line (generated from unmodified configure.ac). This got further,
but failed building lisp:

------------------------------------------------------------------
cd ../lisp; /usr/bin/make -w update-subdirs
make[2]: Entering directory `/c/emacs/src/emacs/trunk/obj-mingw32/lisp'
cd ../../lisp; subdirs=`find . -type d -print`; for file in $subdirs; do case $file in */.* | */.*/* | */=* | */cedet* ) ;; *) wins="$wins${wins:+ }$file" ;; esac; done; \
        for file in $wins; do \
           ../../build-aux/update-subdirs $file; \
        done;
/bin/sh: line 2: ../../build-aux/update-subdirs: No such file or directory
/bin/sh: line 2: ../../build-aux/update-subdirs: No such file or directory
------------------------------------------------------------------

The for loop runs from trunk/lisp, so the path to trunk/build-aux is wrong.
In addition, this use of find and a for loop does not look correct for
directory paths with spaces.

Let me know if you need any help with testing, build logs etc.

    AndyM

Message #26 received at 15675 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 15675 <at> debbugs.gnu.org
Subject: Re: bug#15675: the configure script invoked before make
Date: Wed, 23 Oct 2013 21:56:47 -0400

Andy Moreton wrote:

> Building in "obj-mingw32/lib" fails because CPP and CPPFLAGS still have
> "-I ../nt/inc", which should either be "-I ../../nt/inc" (relative to
> "obj-mingw32") or be absolute.

Yes, I posted about that on emacs-devel a little earlier, see
http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00733.html

> /bin/sh: line 2: ../../build-aux/update-subdirs: No such file or directory

Should be fixed now.

> In addition, this use of find and a for loop does not look correct for
> directory paths with spaces.

The found directories are relative paths within the Emacs repo and won't
contain spaces.

Message #29 received at 15675 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 15675 <at> debbugs.gnu.org
Subject: Re: bug#15675: the configure script invoked before make
Date: Wed, 23 Oct 2013 22:16:32 -0400

Glenn Morris wrote:

>> Building in "obj-mingw32/lib" fails because CPP and CPPFLAGS still have
>> "-I ../nt/inc",

? Why does CPP contain flags at all? Sounds wrong.

> Yes, I posted about that on emacs-devel a little earlier, see
> http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00733.html

I installed my guess at a solution...

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#15675: the configure script invoked before make
Date: Thu, 24 Oct 2013 04:44:35 +0100

On Thu 24 Oct 2013, Glenn Morris wrote:

> Glenn Morris wrote:
>
>>> Building in "obj-mingw32/lib" fails because CPP and CPPFLAGS still have
>>> "-I ../nt/inc",
>
> ? Why does CPP contain flags at all? Sounds wrong.

With your updated configury from r114769, obj-mingw32/lib/Makefile has:

CPP = gcc -I ../nt/inc -E
CPPFLAGS = -mtune=pentium4   -IC:/emacs/mingw-devel/include -IC:/emacs/mingw-devel/src/xpm/3.5.1/libXpm-3.5.1-src/lib -DUSE_CRT_DLL=1 -I ${abs_top_srcdir}/nt/inc

Not sure where that comes from though...

>> Yes, I posted about that on emacs-devel a little earlier, see
>> http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00733.html
>
> I installed my guess at a solution...

Thanks for looking at this. There is still a build error in that the the
paths using $abs_top_srcdir don't expand properly. I've tracked this
down to the trailing tab and comment in the Makefile.in files:

abs_top_srcdir=@abs_top_srcdir@        # MinGW CPPFLAGS may use this

Removing the tab and the comment in all the Makefile.in files fixed
things for me.

    AndyM

Message #35 received at 15675 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 15675 <at> debbugs.gnu.org
Subject: Re: bug#15675: the configure script invoked before make
Date: Thu, 24 Oct 2013 00:07:01 -0400

Andy Moreton wrote:

> CPP = gcc -I ../nt/inc -E

Seems wrong to me for CPP to contain any -I option. Where does that come from?

> CPPFLAGS = -mtune=pentium4   -IC:/emacs/mingw-devel/include -IC:/emacs/mingw-devel/src/xpm/3.5.1/libXpm-3.5.1-src/lib -DUSE_CRT_DLL=1 -I ${abs_top_srcdir}/nt/inc

Looks ok to me.

> abs_top_srcdir=@abs_top_srcdir@        # MinGW CPPFLAGS may use this
>
> Removing the tab and the comment in all the Makefile.in files fixed
> things for me.

Whoops; fixed.

Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#15675: the configure script invoked before make
Date: Thu, 24 Oct 2013 15:48:01 +0100

On Thu 24 Oct 2013, Glenn Morris wrote:

> Andy Moreton wrote:
>
>> CPP = gcc -I ../nt/inc -E
>
> Seems wrong to me for CPP to contain any -I option. Where does that come from?
>
>> CPPFLAGS = -mtune=pentium4 -IC:/emacs/mingw-devel/include
>> -IC:/emacs/mingw-devel/src/xpm/3.5.1/libXpm-3.5.1-src/lib -DUSE_CRT_DLL=1 -I
>> ${abs_top_srcdir}/nt/inc
>
> Looks ok to me.
>
>> abs_top_srcdir=@abs_top_srcdir@        # MinGW CPPFLAGS may use this
>>
>> Removing the tab and the comment in all the Makefile.in files fixed
>> things for me.
>
> Whoops; fixed.

Thanks. I've successfully bootstrapped from bzr r114777 today, so I
think you can declare victory.

    AndyM

Message #41 received at 15675 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 15675 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15675: the configure script invoked before make
Date: Thu, 24 Oct 2013 19:11:32 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Date: Thu, 24 Oct 2013 00:07:01 -0400
> Cc: 15675 <at> debbugs.gnu.org
> 
> Andy Moreton wrote:
> 
> > CPP = gcc -I ../nt/inc -E
> 
> Seems wrong to me for CPP to contain any -I option. Where does that come from?

From the configure script.

The story begins, innocently enough, here:

    case "${canonical}" in
      *-darwin* )               opsys=darwin ;;
      *-mingw32 )
		opsys=mingw32
		# MinGW overrides and adds some system headers in nt/inc.
		GCC_TEST_OPTIONS="-I $srcdir/nt/inc"

(MinGW needs the test programs to pick up headers in nt/inc, since
those headers define some stuff which is not available in the MinGW
system headers.  This is what GCC_TEST_OPTIONS are for, right?)

Then the configure script sets CC to something that uses these
switches:

  if test x$GCC = xyes; then
    test "x$GCC_TEST_OPTIONS" != x && CC="$CC $GCC_TEST_OPTIONS"

So far, so good.  But then:

  { $as_echo "$as_me:${as_lineno-$LINENO}: checking how to run the C preprocessor" >&5
  $as_echo_n "checking how to run the C preprocessor... " >&6; }
  # On Suns, sometimes $CPP names a directory.
  if test -n "$CPP" && test -d "$CPP"; then
    CPP=
  fi
  if test -z "$CPP"; then
    if test "${ac_cv_prog_CPP+set}" = set; then :
    $as_echo_n "(cached) " >&6
  else
	# Double quotes because CPP needs to be expanded
      for CPP in "$CC -E" "$CC -E -traditional-cpp" "/lib/cpp"
      do         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  [...]
      done
      ac_cv_prog_CPP=$CPP

  fi
    CPP=$ac_cv_prog_CPP

This sets CPP to "$CC -E", and the rest, as they say, is history.

The problem here seems to be that the script confuses the value of CPP
needed to run the test programs with the value of CPP that is needed
to be substituted for @CPP@.  The latter should have any
GCC_TEST_OPTIONS removed from it.

Message #44 received at 15675 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15675 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15675: the configure script invoked before make
Date: Thu, 24 Oct 2013 17:30:00 -0400

Eli Zaretskii wrote:

> (MinGW needs the test programs to pick up headers in nt/inc, since
> those headers define some stuff which is not available in the MinGW
> system headers.  This is what GCC_TEST_OPTIONS are for, right?)

I don't really know what *GCC_TEST_OPTIONS is for.
The only thing in configure using it apart from MinGW is Irix,
which frankly is used by ~ no-one.

Emacs autoconf usage is not always best-practice...
It seems to me that both the Irix and MinGW cases should be using
C(PP)FLAGS instead of using GCC_TEST_OPTIONS to modify CC.

Message #47 received at 15675 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 15675 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15675: the configure script invoked before make
Date: Fri, 25 Oct 2013 09:38:47 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: andrewjmoreton <at> gmail.com,  15675 <at> debbugs.gnu.org
> Date: Thu, 24 Oct 2013 17:30:00 -0400
> 
> It seems to me that both the Irix and MinGW cases should be using
> C(PP)FLAGS instead of using GCC_TEST_OPTIONS to modify CC.

That was the first thing I tried back when I worked on configuring
MinGW with the configure script.  But it doesn't fly too well, either.
I don't exactly remember the details, but I think the flags ended
up twice in the compilation command, once from CPPFLAGS and another
time from CFLAGS.  Or something like that.

These are all minor issues, but so is the fact that CPP includes
switches.  And CPP is only used by lib/Makefile.in.  So these are nits
in any case.

Message #50 received at 15675 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rgm <at> gnu.org
Cc: 15675 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#15675: the configure script invoked before make
Date: Fri, 25 Oct 2013 11:45:47 +0300

> Date: Fri, 25 Oct 2013 09:38:47 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 15675 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
> 
> > From: Glenn Morris <rgm <at> gnu.org>
> > Cc: andrewjmoreton <at> gmail.com,  15675 <at> debbugs.gnu.org
> > Date: Thu, 24 Oct 2013 17:30:00 -0400
> > 
> > It seems to me that both the Irix and MinGW cases should be using
> > C(PP)FLAGS instead of using GCC_TEST_OPTIONS to modify CC.
> 
> That was the first thing I tried back when I worked on configuring
> MinGW with the configure script.  But it doesn't fly too well, either.
> I don't exactly remember the details, but I think the flags ended
> up twice in the compilation command, once from CPPFLAGS and another
> time from CFLAGS.  Or something like that.
> 
> These are all minor issues, but so is the fact that CPP includes
> switches.  And CPP is only used by lib/Makefile.in.  So these are nits
> in any case.

Actually, having these flags twice on the command line is not a minor
problem: some headers in nt/inc use #include_next, which will not DTRT
if -I../nt/inc is seen more than once on the command line.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.