Re: trunk r115773: Port xcrun configuration to GNU/Linux.

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Glenn Morris]

xcsdkdir=
AC_CHECK_PROGS(XCRUN, [xcrun])
if test -n "$XCRUN"; then
  AC_CHECK_PROGS(MAKE, [make "$XCRUN make"])
  test -n "$MAKE" && export MAKE
  xcsdkdir=`$XCRUN --show-sdk-path 2>/dev/null`
fi

I don't have "xcrun" installed. So AC_CHECK_PROGS never tests for make.
This results in lib/Makefile containing

  MAKE = 

for me. This is obviously A Bad Thing. Eg:

  make -C lib
  /bin/bash: all-am: command not found


(I'm loving this feature freeze as much as usual.)

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Paul Eggert]

Glenn Morris wrote:
> (I'm loving this feature freeze as much as usual.)

Me too!  In trunk bzr 115782 I fixed the problem you
reported on GNU/Linux, but can't easily test this stuff
on OS X.

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Jan Djärv]

Hello.

28 dec 2013 kl. 01:42 skrev Paul Eggert <eggert@cs.ucla.edu>:

> Glenn Morris wrote:
>> (I'm loving this feature freeze as much as usual.)
> 
> Me too!  In trunk bzr 115782 I fixed the problem you
> reported on GNU/Linux, but can't easily test this stuff
> on OS X.

Didn't work there, I checked in a fix.

	Jan D.

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 27 Dec 2013 16:42:25 -0800, Paul Eggert <eggert@cs.ucla.edu> said:

> Glenn Morris wrote:
>> (I'm loving this feature freeze as much as usual.)

> Me too!  In trunk bzr 115782 I fixed the problem you reported on
> GNU/Linux, but can't easily test this stuff on OS X.

You changed

  CPPFLAGS="$CPPFLAGS -I$xcsdkdir/usr/include/libxml2"

to

  CPPFLAGS="$CPPFLAGS -I'$xcsdkdir/usr/include/libxml2'"

in r115773.  But it actually does not work as you might expect,
because it is used in the context like this:

  ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
	:
  (eval "$ac_compile") 2>conftest.err

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Paul Eggert]

YAMAMOTO Mitsuharu wrote:
> You changed
> 
>   CPPFLAGS="$CPPFLAGS -I$xcsdkdir/usr/include/libxml2"
> 
> to
> 
>   CPPFLAGS="$CPPFLAGS -I'$xcsdkdir/usr/include/libxml2'"
> 
> in r115773.  But it actually does not work as you might expect,

Thanks, I changed it to:

  CPPFLAGS=$CPPFLAGS' -I"$xcsdkdir"/usr/include/libxml2'

in trunk bzr 115801.  I can't easily test this, as I don't
use OS X, so please let me know of are any further problems.

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 28 Dec 2013 23:16:12 -0800, Paul Eggert <eggert@cs.ucla.edu> said:

> YAMAMOTO Mitsuharu wrote:
>> You changed
>> 
>> CPPFLAGS="$CPPFLAGS -I$xcsdkdir/usr/include/libxml2"
>> 
>> to
>> 
>> CPPFLAGS="$CPPFLAGS -I'$xcsdkdir/usr/include/libxml2'"
>> 
>> in r115773.  But it actually does not work as you might expect,

> Thanks, I changed it to:

>   CPPFLAGS=$CPPFLAGS' -I"$xcsdkdir"/usr/include/libxml2'

> in trunk bzr 115801.  I can't easily test this, as I don't use OS X,
> so please let me know of are any further problems.

It doesn't work either.  The "eval" command interprets *, ?, [...],
and blanks after the parameter expansion for $CPPFLAGS, but it does
not strip quotes/escapes in the result of the parameter expansion.  So
you cannot put quotes in the value of CPPFLAGS.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Paul Eggert]

YAMAMOTO Mitsuharu wrote:
> you cannot put quotes in the value of CPPFLAGS.

Ah, OK, thanks, I reverted the change.

If someone ever has spaces in xcsdkdir's value
they can worry about fixing this.

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 28 Dec 2013 23:51:47 -0800, Paul Eggert <eggert@cs.ucla.edu> said:

> YAMAMOTO Mitsuharu wrote:
>> you cannot put quotes in the value of CPPFLAGS.

> Ah, OK, thanks, I reverted the change.

> If someone ever has spaces in xcsdkdir's value they can worry about
> fixing this.

Yes.  Actually it is not so uncommon to have spaces as a part of a
volume name (e.g., /Volumes/Macintosh HD/Applications/Xcode.app/...).
That's why I didn't apply the patch in
http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00760.html to
the Mac port.

I'd encourage those who build Emacs themselves to install the Command
Line Developer Tools on Mavericks (i.e., $ xcode-select --install) so
they have /usr/include directory, which does not exist by default.
But an alternative idea might be to try xcsdkdir only if it does not
contain *, ?, [, or blanks.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

() YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
() Sun, 29 Dec 2013 17:16:29 +0900

   Yes.  Actually it is not so uncommon to have spaces as a part of a
   volume name (e.g., /Volumes/Macintosh HD/Applications/Xcode.app/...).

How about making a symlink (w/o space!) from the builddir and adding
that to ‘CPPFLAGS’?  Something like:

 ln -f -s "$xcsdkdir" fake-xcsdkdir
 xcsdkdir=`pwd`/fake-xcsdkdir
 AS_VAR_APPEND([CPPFLAGS],[ -I$xcsdkdir/usr/include/libxml2])

The kludge can be conditionalized on space-detection, i suppose.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[chad]

On 29 Dec 2013, at 01:11, Thien-Thi Nguyen <ttn@gnu.org> wrote:

> () YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> () Sun, 29 Dec 2013 17:16:29 +0900
> 
>   Yes.  Actually it is not so uncommon to have spaces as a part of a
>   volume name (e.g., /Volumes/Macintosh HD/Applications/Xcode.app/…).

It’s certainly not uncommon to have a space in a volume name, but it’s pretty uncommon in my (limited) experience to use the volume name at all. The above would be written as "/Applications/Xcode.app/…" on every macosx development system I’ve seen, but that’s not a large number. Does that help?

~Chad

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 29 Dec 2013 02:44:16 -0800, chad <chadpbrown@gmail.com> said:

> On 29 Dec 2013, at 01:11, Thien-Thi Nguyen <ttn@gnu.org> wrote:

>> Yes.  Actually it is not so uncommon to have spaces as a part of a
>> volume name (e.g., /Volumes/Macintosh HD/Applications/Xcode.app/…).

> It’s certainly not uncommon to have a space in a volume name, but
> it’s pretty uncommon in my (limited) experience to use the volume
> name at all. The above would be written as
> "/Applications/Xcode.app/…" on every macosx development system I’ve
> seen, but that’s not a large number. Does that help?

Xcode 5 supports both Mountain Lion and Mavericks, and if you have one
partition for each version on the same machine, then you don't have to
install two instances of Xcode 5.  Actually, I install Xcode 5 only in
the Mountain Lion partition and use it from Mavericks on my laptop.
In such a case, xcrun --show-sdk-path prints
/Volumes/VOLUME_NAME_FOR_MOUNTAIN_LION/Applications/Xcode.app/...

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Sun, 29 Dec 2013 10:11:16 +0100
> 
> How about making a symlink (w/o space!) from the builddir and adding
> that to ‘CPPFLAGS’?

So we are going to support builddir with blanks on MS-Windows, but not
on Posix platforms?  Ts-ts-ts...

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Jan Djärv]

Hello. 

29 dec 2013 kl. 16:49 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Thien-Thi Nguyen <ttn@gnu.org>
>> Date: Sun, 29 Dec 2013 10:11:16 +0100
>> 
>> How about making a symlink (w/o space!) from the builddir and adding
>> that to ‘CPPFLAGS’?
> 
> So we are going to support builddir with blanks on MS-Windows, but not
> on Posix platforms?  Ts-ts-ts...

This has nothing to do with builddir, but include directories passed to the compiler with -I.  As this has to do with the configure code and how it handles spaces, I'm pretty sure this fails everywhere. 

    Jan D. 

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sun, 29 Dec 2013 19:41:28 +0100
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> This has nothing to do with builddir, but include directories passed to the compiler with -I.  As this has to do with the configure code and how it handles spaces, I'm pretty sure this fails everywhere. 

The solution might be to use relative file names.

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Jan Djärv]

Hello.

29 dec 2013 kl. 20:01 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Sun, 29 Dec 2013 19:41:28 +0100
>> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>> 
>> This has nothing to do with builddir, but include directories passed to the compiler with -I.  As this has to do with the configure code and how it handles spaces, I'm pretty sure this fails everywhere. 
> 
> The solution might be to use relative file names.

It would not help here, the trees are urelated.
I.e. the relative path would also have a space in it, something like:

../../../../Volumes/Macintosh HD/...

	Jan D.

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sun, 29 Dec 2013 22:04:02 +0100
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> Hello.
> 
> 29 dec 2013 kl. 20:01 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> >> From: Jan Djärv <jan.h.d@swipnet.se>
> >> Date: Sun, 29 Dec 2013 19:41:28 +0100
> >> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> >> 
> >> This has nothing to do with builddir, but include directories passed to the compiler with -I.  As this has to do with the configure code and how it handles spaces, I'm pretty sure this fails everywhere. 
> > 
> > The solution might be to use relative file names.
> 
> It would not help here, the trees are urelated.
> I.e. the relative path would also have a space in it, something like:
> 
> ../../../../Volumes/Macintosh HD/...

How about stuffing the file name into an environment variable, and
using that in configure?

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Jan Djärv]

Hello.

29 dec 2013 kl. 22:16 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Sun, 29 Dec 2013 22:04:02 +0100
>> Cc: emacs-devel <emacs-devel@gnu.org>
>> 
>> Hello.
>> 
>> 29 dec 2013 kl. 20:01 skrev Eli Zaretskii <eliz@gnu.org>:
>> 
>>>> From: Jan Djärv <jan.h.d@swipnet.se>
>>>> Date: Sun, 29 Dec 2013 19:41:28 +0100
>>>> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>>>> 
>>>> This has nothing to do with builddir, but include directories passed to the compiler with -I.  As this has to do with the configure code and how it handles spaces, I'm pretty sure this fails everywhere. 
>>> 
>>> The solution might be to use relative file names.
>> 
>> It would not help here, the trees are urelated.
>> I.e. the relative path would also have a space in it, something like:
>> 
>> ../../../../Volumes/Macintosh HD/...
> 
> How about stuffing the file name into an environment variable, and
> using that in configure?

Good try, but no.  I think this is impossible without modifying configure variables, i.e. ac_compile.

ac_compile is:

  ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'

As said, it is used like this:

  (eval "$ac_compile") 2>conftest.err

Eval first expands the variables, and then word splits on whitespace, regardless of quoting characters.
So there is no way to put something in CPPFLAGS with a whitespace that eval wont word-split on that whitespace.
This is a fundamental limitation in autoconf.

I'm happy to be proven wrong, but I can't see any way to do it, except modifying ac_compile.

	Jan D.

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Jan Djärv]

Hello.

29 dec 2013 kl. 09:16 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:

>>>>>> On Sat, 28 Dec 2013 23:51:47 -0800, Paul Eggert <eggert@cs.ucla.edu> said:
> 
>> YAMAMOTO Mitsuharu wrote:
>>> you cannot put quotes in the value of CPPFLAGS.
> 
>> Ah, OK, thanks, I reverted the change.
> 
>> If someone ever has spaces in xcsdkdir's value they can worry about
>> fixing this.
> 

Too bad autoconf is so bad at space handling.

> Yes.  Actually it is not so uncommon to have spaces as a part of a
> volume name (e.g., /Volumes/Macintosh HD/Applications/Xcode.app/...).
> That's why I didn't apply the patch in
> http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00760.html to
> the Mac port.
> 

We only need to use xcsdkdir if xcrun is used, I made that change.

> I'd encourage those who build Emacs themselves to install the Command
> Line Developer Tools on Mavericks (i.e., $ xcode-select --install) so
> they have /usr/include directory, which does not exist by default.

Last I checked, that required an additional registration.  Some people are not comfortable with that.
Also, upgrading Xcode is easier if xcrun is used.

	Jan D.

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 29 Dec 2013 14:21:14 +0100, Jan Djärv <jan.h.d@swipnet.se> said:

>> Yes.  Actually it is not so uncommon to have spaces as a part of a
>> volume name (e.g., /Volumes/Macintosh
>> HD/Applications/Xcode.app/...).  That's why I didn't apply the
>> patch in
>> http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00760.html
>> to the Mac port.
>> 

> We only need to use xcsdkdir if xcrun is used, I made that change.

I don't think that is correct at least for Mavericks.  See below.

>> I'd encourage those who build Emacs themselves to install the
>> Command Line Developer Tools on Mavericks (i.e., $ xcode-select
>> --install) so they have /usr/include directory, which does not
>> exist by default.

> Last I checked, that required an additional registration.  Some
> people are not comfortable with that.  Also, upgrading Xcode is
> easier if xcrun is used.

I actually have one experimental Mavericks installation where the
Command Line Developer Tools are not installed.  Still there exists
/usr/bin/gcc as a wrapper to execute gcc in the active developer
directory (see man page of xcode-select(1)), and `configure' thinks it
doesn't need to use xcrun to run gcc.  But the directory /usr/include
does not exist and you need to use xcsdkdir for the libxml2 headers.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Jan Djärv]

Hello.

29 dec 2013 kl. 14:55 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:

>>>>>> On Sun, 29 Dec 2013 14:21:14 +0100, Jan Djärv <jan.h.d@swipnet.se> said:
> 
>>> Yes.  Actually it is not so uncommon to have spaces as a part of a
>>> volume name (e.g., /Volumes/Macintosh
>>> HD/Applications/Xcode.app/...).  That's why I didn't apply the
>>> patch in
>>> http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00760.html
>>> to the Mac port.
>>> 
> 
>> We only need to use xcsdkdir if xcrun is used, I made that change.
> 
> I don't think that is correct at least for Mavericks.  See below.
> 
>>> I'd encourage those who build Emacs themselves to install the
>>> Command Line Developer Tools on Mavericks (i.e., $ xcode-select
>>> --install) so they have /usr/include directory, which does not
>>> exist by default.
> 
>> Last I checked, that required an additional registration.  Some
>> people are not comfortable with that.  Also, upgrading Xcode is
>> easier if xcrun is used.
> 
> I actually have one experimental Mavericks installation where the
> Command Line Developer Tools are not installed.  Still there exists
> /usr/bin/gcc as a wrapper to execute gcc in the active developer
> directory (see man page of xcode-select(1)), and `configure' thinks it
> doesn't need to use xcrun to run gcc.  But the directory /usr/include
> does not exist and you need to use xcsdkdir for the libxml2 headers.

Its a good thing then that configure doesn't look for gcc, but for make, to determine if xcrun is to be used.
Does this gcc wrapper come from an earlier upgraded installation, or is this a clean Mavericks install?

	Jan D.

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Jan Djärv]

Hello.

29 dec 2013 kl. 17:28 skrev Jan Djärv <jan.h.d@swipnet.se>:

> Hello.
> 
> 29 dec 2013 kl. 14:55 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:
> 
>> I actually have one experimental Mavericks installation where the
>> Command Line Developer Tools are not installed.  Still there exists
>> /usr/bin/gcc as a wrapper to execute gcc in the active developer
>> directory (see man page of xcode-select(1)), and `configure' thinks it
>> doesn't need to use xcrun to run gcc.  But the directory /usr/include
>> does not exist and you need to use xcsdkdir for the libxml2 headers.
> 
> Its a good thing then that configure doesn't look for gcc, but for make, to determine if xcrun is to be used.
> Does this gcc wrapper come from an earlier upgraded installation, or is this a clean Mavericks install?

A clean install does put make in /usr/bin, but it is not a real make.  It pops up a dialog, suggesting to install developer tools.  Ditto for /usr/bin/gcc.  Not sure how to detect this, except detecting Mavericks (and later??).

	Jan D.

Re: trunk r115773: Port xcrun configuration to GNU/Linux.

[Jan Djärv]

Hello.

28 dec 2013 kl. 00:50 skrev Glenn Morris <rgm@gnu.org>:

> 
> xcsdkdir=
> AC_CHECK_PROGS(XCRUN, [xcrun])
> if test -n "$XCRUN"; then
>  AC_CHECK_PROGS(MAKE, [make "$XCRUN make"])
>  test -n "$MAKE" && export MAKE
>  xcsdkdir=`$XCRUN --show-sdk-path 2>/dev/null`
> fi
> 
> I don't have "xcrun" installed. So AC_CHECK_PROGS never tests for make.
> This results in lib/Makefile containing
> 
>  MAKE = 
> 
> for me. This is obviously A Bad Thing. Eg:
> 
>  make -C lib
>  /bin/bash: all-am: command not found

This is strange, as configure itself sets MAKE later on.  That is why this is early, to override the later setting.  Are you running on a Darwin system?

> 
> 
> (I'm loving this feature freeze as much as usual.)

Compiling Emacs is considered a new feature?

	Jan D.