GNU bug report logs - #19850
25.0.50; [PATCH] configure.ac: Fix site-lisp paths with NS self-contained apps.

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 19850 in the body.
You can then email your comments to 19850 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: David Caldwell <david <at> porkrind.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; [PATCH] configure.ac: Fix site-lisp paths with NS
 self-contained apps.
Date: Thu, 12 Feb 2015 13:51:28 -0800

[Message part 1 (text/plain, inline)]

When building a self contained Mac OS X app, the site-lisp dir that gets
inserted into `load-path` is not very useful, since it points to the
Emacs.app in `nextstep/` where emacs was compiled. For example:

"/Users/build/workspace/Emacs-Multi-Build/label/mavericks/emacs-source/nextstep/Emacs.app/Contents/Resources/share/emacs/24.4/site-lisp"

I think the site lisp path should be in `/Library/emacs` instead. Here
is a patch to do just that (created with `git format-patch`, is that
convenient? I don't know what works best in these cases).

I patched the trunk, but on reflection, it seems like this should go in
the 24 branch, too.

-David

From c20e8816f3905fa3ec6f82a7f566f7ce32dc178b Mon Sep 17 00:00:00 2001
From: David Caldwell <david <at> porkrind.org>
Date: Thu, 12 Feb 2015 13:31:36 -0800
Subject: [PATCH] configure.ac: Fix site-lisp paths with NS self-contained
 apps.

* configure.ac (HAVE_NS): When self-contained, set datarootdir to
/Library so PATH_SITELOADSEARCH path points there instead of inside
the Emacs.app build dir.
---
 configure.ac | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configure.ac b/configure.ac
index 68291b8..3e44a93 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1872,6 +1872,8 @@ if test "${HAVE_NS}" = yes; then
      mandir="\${ns_appresdir}/man"
      lispdir="\${ns_appresdir}/lisp"
      INSTALL_ARCH_INDEP_EXTRA=
+     # This is so PATH_SITELOADSEARCH gets set to /Library/emacs/...
+     datarootdir=/Library
   fi

   NS_OBJC_OBJ="nsterm.o nsfns.o nsmenu.o nsselect.o nsimage.o $ns_fontfile"
--
2.2.2

[mac-site-lisp-path.patch (text/plain, attachment)]

[smime.p7s (application/pkcs7-signature, attachment)]

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

From: "Jan D." <jan.h.d <at> swipnet.se>
To: David Caldwell <david <at> porkrind.org>
Cc: 19850 <at> debbugs.gnu.org
Subject: Re: bug#19850: 25.0.50;
 [PATCH] configure.ac: Fix site-lisp paths with NS self-contained apps.
Date: Fri, 13 Feb 2015 07:57:13 +0100

Hi.

If we keep site-lis as it is, we can have several Emacs versions installed, with different site-lisp:s. Also, changing files in site-lisp does not require root priviliges.
Your change breaks both those feaures.

I don't think this is a good idea.

	Jan D.

> 12 feb 2015 kl. 22:51 skrev David Caldwell <david <at> porkrind.org>:
> 
> 
> When building a self contained Mac OS X app, the site-lisp dir that gets
> inserted into `load-path` is not very useful, since it points to the
> Emacs.app in `nextstep/` where emacs was compiled. For example:
> 
> "/Users/build/workspace/Emacs-Multi-Build/label/mavericks/emacs-source/nextstep/Emacs.app/Contents/Resources/share/emacs/24.4/site-lisp"
> 
> I think the site lisp path should be in `/Library/emacs` instead. Here
> is a patch to do just that (created with `git format-patch`, is that
> convenient? I don't know what works best in these cases).
> 
> I patched the trunk, but on reflection, it seems like this should go in
> the 24 branch, too.
> 
> -David
> 
> From c20e8816f3905fa3ec6f82a7f566f7ce32dc178b Mon Sep 17 00:00:00 2001
> From: David Caldwell <david <at> porkrind.org>
> Date: Thu, 12 Feb 2015 13:31:36 -0800
> Subject: [PATCH] configure.ac: Fix site-lisp paths with NS self-contained
> apps.
> 
> * configure.ac (HAVE_NS): When self-contained, set datarootdir to
> /Library so PATH_SITELOADSEARCH path points there instead of inside
> the Emacs.app build dir.
> ---
> configure.ac | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/configure.ac b/configure.ac
> index 68291b8..3e44a93 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1872,6 +1872,8 @@ if test "${HAVE_NS}" = yes; then
>      mandir="\${ns_appresdir}/man"
>      lispdir="\${ns_appresdir}/lisp"
>      INSTALL_ARCH_INDEP_EXTRA=
> +     # This is so PATH_SITELOADSEARCH gets set to /Library/emacs/...
> +     datarootdir=/Library
>   fi
> 
>   NS_OBJC_OBJ="nsterm.o nsfns.o nsmenu.o nsselect.o nsimage.o $ns_fontfile"
> --
> 2.2.2
> <mac-site-lisp-path.patch>

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

From: David Caldwell <david <at> porkrind.org>
To: "Jan D." <jan.h.d <at> swipnet.se>
Cc: 19850 <at> debbugs.gnu.org
Subject: Re: bug#19850: 25.0.50; [PATCH] configure.ac: Fix site-lisp
 paths with NS self-contained apps.
Date: Thu, 12 Feb 2015 23:28:42 -0800

[Message part 1 (text/plain, inline)]

On 2/12/15 10:57 PM, Jan D. wrote:
> Hi.
> 
> If we keep site-lis as it is, we can have several Emacs versions installed, with different site-lisp:s.
> Also, changing files in site-lisp does not require root priviliges.

If we keep things as they are now, the site lisp file points to a random
directory that doesn't exist! Take a look again:

>> "/Users/build/workspace/Emacs-Multi-Build/label/mavericks/emacs-source/nextstep/Emacs.app/Contents/Resources/share/emacs/24.4/site-lisp"

This Emacs was built on a different machine than the one it's running
on. My machine has no "build" user and therefore no "/Users/build"
directory.

I certainly cannot create that directory without being root.

> Your change breaks both those feaures.

No, it actually doesn't. First off, it only affects self contained
nextstep builds, which (as I described above) are currently totally busted.

Secondly, it doesn't preclude different site lisps for different
Emacsen. Here's the epaths.h line generated with my patch:

#define PATH_SITELOADSEARCH
"/Library/emacs/25.0.50/site-lisp:/Library/emacs/site-lisp"

That still ends up with the version in the site lisp path, so there can
multiple site lisps.

Yes, the site lisp path is in /Library which is root:wheel, but that is
the correct place to put site wide things on the Mac. If you want
non-site wide lisps, you can always edit your .emacs with no root
privileges. Thinking about it, I'm not sure why non-root is a good idea
for site wide stuff in the first place: On a multi-user system, it seems
like a security problem for one user to affect all the other user's
site-lisp. That *should* require root (like it does on linux).

> I don't think this is a good idea.

Please reconsider. This really seems like the correct fix to me.

-David

[smime.p7s (application/pkcs7-signature, attachment)]

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

From: "Jan D." <jan.h.d <at> swipnet.se>
To: David Caldwell <david <at> porkrind.org>
Cc: 19850 <at> debbugs.gnu.org
Subject: Re: bug#19850: 25.0.50; [PATCH] configure.ac: Fix site-lisp paths
 with NS self-contained apps.
Date: Fri, 13 Feb 2015 14:41:10 +0100

David Caldwell skrev den 2015-02-13 08:28:
> On 2/12/15 10:57 PM, Jan D. wrote:
>> Hi.
>>
>> If we keep site-lis as it is, we can have several Emacs versions installed, with different site-lisp:s.
>> Also, changing files in site-lisp does not require root priviliges.
>
> If we keep things as they are now, the site lisp file points to a random
> directory that doesn't exist! Take a look again:
>
>>> "/Users/build/workspace/Emacs-Multi-Build/label/mavericks/emacs-source/nextstep/Emacs.app/Contents/Resources/share/emacs/24.4/site-lisp"
>

Oh, its the compile time place, not the run time. That looks like a bug.

> This Emacs was built on a different machine than the one it's running
> on. My machine has no "build" user and therefore no "/Users/build"
> directory.
>
> I certainly cannot create that directory without being root.
>
>> Your change breaks both those feaures.
>
> No, it actually doesn't. First off, it only affects self contained
> nextstep builds, which (as I described above) are currently totally busted.
>
> Secondly, it doesn't preclude different site lisps for different
> Emacsen. Here's the epaths.h line generated with my patch:
>
> #define PATH_SITELOADSEARCH
> "/Library/emacs/25.0.50/site-lisp:/Library/emacs/site-lisp"
>
> That still ends up with the version in the site lisp path, so there can
> multiple site lisps.
>
> Yes, the site lisp path is in /Library which is root:wheel, but that is
> the correct place to put site wide things on the Mac.

No its not, its /Library/Application Support/Emacs.


> If you want
> non-site wide lisps, you can always edit your .emacs with no root
> privileges. Thinking about it, I'm not sure why non-root is a good idea
> for site wide stuff in the first place: On a multi-user system, it seems
> like a security problem for one user to affect all the other user's
> site-lisp. That *should* require root (like it does on linux).
>

That's not the point.  The point is that the Emacs I compile for myself 
should by default ignore site wide stuff in global places.  It should 
require a choice to use it.  On Linux-distributions site lisp always 
looks like a garbage heap full of bad ideas dumped there by who-nows. 
And that's when installing a fresh distribution.

>> I don't think this is a good idea.
>
> Please reconsider. This really seems like the correct fix to me.
>

This is not the correct fix.  But we might add something for those that 
want a global site-lisp.  I'll think about it.

	Jan D.

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

From: "Jan D." <jan.h.d <at> swipnet.se>
To: David Caldwell <david <at> porkrind.org>
Cc: 19850 <at> debbugs.gnu.org
Subject: Re: bug#19850: 25.0.50;
 [PATCH] configure.ac: Fix site-lisp paths with NS self-contained apps.
Date: Fri, 13 Feb 2015 17:36:53 +0100

You should be able to get what you want at configure time by adding

--enable-locallisppath='/Library/emacs/site-lisp'

	Jan D.

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

From: "Jan D." <jan.h.d <at> swipnet.se>
To: David Caldwell <david <at> porkrind.org>
Cc: 19850-done <at> debbugs.gnu.org
Subject: Re: bug#19850: 25.0.50;
 [PATCH] configure.ac: Fix site-lisp paths with NS self-contained apps.
Date: Fri, 13 Feb 2015 17:46:02 +0100

I have fixed in trunk so that directories pointing to the build dir is not in loadpath.

	Jan D.

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

From: David Caldwell <david <at> porkrind.org>
To: "Jan D." <jan.h.d <at> swipnet.se>
Cc: 19850 <at> debbugs.gnu.org
Subject: Re: bug#19850: 25.0.50; [PATCH] configure.ac: Fix site-lisp
 paths with NS self-contained apps.
Date: Fri, 13 Feb 2015 11:41:28 -0800

[Message part 1 (text/plain, inline)]

On 2/13/15 5:41 AM, Jan D. wrote:
> David Caldwell skrev den 2015-02-13 08:28:
>> On 2/12/15 10:57 PM, Jan D. wrote:

>> #define PATH_SITELOADSEARCH
>> "/Library/emacs/25.0.50/site-lisp:/Library/emacs/site-lisp"

>> Yes, the site lisp path is in /Library which is root:wheel, but that is
>> the correct place to put site wide things on the Mac.
> 
> No its not, its /Library/Application Support/Emacs.

If that is your main objection, I wouldn't mind that at all. I chose
plain /Library/emacs as it is similar to /Library/Perl and because it
was the minimal patch. /Library/Emacs would be better but the lowercase
"emacs" was chosen earlier and I didn't want to duplicate the

locallisppath='${datadir}/emacs/${version}/site-lisp:'\
'${datadir}/emacs/site-lisp'

lines.

Though in retrospect I think what I did is too oblique. It would be a
better patch to just do that explicitly:

locallisppath='/Library/Application Support/Emacs/${version}/site-lisp:'\
'/Library/Application Support/Emacs/site-lisp'

>> If you want non-site wide lisps, you can always edit your .emacs
>> with no root privileges. Thinking about it, I'm not sure why
>> non-root is a good idea for site wide stuff in the first place: On
>> a multi-user system, it seems like a security problem for one user
>> to affect all the other user's site-lisp. That *should* require
>> root (like it does on linux).
> 
> That's not the point.  The point is that the Emacs I compile for myself
> should by default ignore site wide stuff in global places.

Then wouldn't it act differently than the Linux version? Don't you get
"/usr/local/emacs/site-lisp" by default there? "/Library" is the
equivalent of "/usr/local" on OS X ("/System/Library" would be "/usr").

> It should require a choice to use it.  On Linux-distributions site
> lisp always looks like a garbage heap full of bad ideas dumped there
> by who-nows. And that's when installing a fresh distribution.

Added by default packages, no doubt. The default OS X Emacs in
/usr/bin/emacs (good old gpl2 version 22.1) uses

    /usr/share/emacs/22.1/lisp/emacs-lisp

On a clean install there's no /Library/Emacs or /Library/Application
Support/Emacs. Emacs installed from homebrew uses

    $(brew --prefix)/share/emacs/${version}/site-lisp

So I believe your fears of default site-lisp garbage are unfounded.

And one could always --disable-locallisppath if they don't want it. I
just think the default should be something reasonable that matches the
other unixes.

> I have fixed in trunk so that directories pointing to the build dir is not in loadpath.

Thanks.

> You should be able to get what you want at configure time by adding
> 
> --enable-locallisppath='/Library/emacs/site-lisp'

Oh, nice, I didn't know that option. It even works with the make
expansion variables:

--enable-locallisppath='/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp'

I suppose I will have to do that unless you change your mind about the
default. :-)

-David

[smime.p7s (application/pkcs7-signature, attachment)]

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

From: "Jan D." <jan.h.d <at> swipnet.se>
To: David Caldwell <david <at> porkrind.org>
Cc: 19850 <at> debbugs.gnu.org
Subject: Re: bug#19850: 25.0.50;
 [PATCH] configure.ac: Fix site-lisp paths with NS self-contained apps.
Date: Sat, 14 Feb 2015 10:25:34 +0100

> 13 feb 2015 kl. 20:41 skrev David Caldwell <david <at> porkrind.org>:
> 
> On 2/13/15 5:41 AM, Jan D. wrote:
>> 
>> 
>> That's not the point.  The point is that the Emacs I compile for myself
>> should by default ignore site wide stuff in global places.
> 
> Then wouldn't it act differently than the Linux version? Don't you get
> "/usr/local/emacs/site-lisp" by default there? "/Library" is the
> equivalent of "/usr/local" on OS X ("/System/Library" would be "/usr").

Yes, I get /usr/local/emacs/site-lisp by default, which is different from the system site-lisp, which is in /usr/share/emacs.
So it takes effort to get your self-built emacs to use the system site-lisp.

Also, /Library is in not the equivalent of /usr/local.  /usr/local is the equivalent of /usr/local.
/Library is a system directory, a mix of /etc and /usr/share.  There are startup daemons there, fonts, internet plugins and so on.  These things are not in /usr/local on any sane Unix-like OS.

	Jan D.

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

From: David Caldwell <david <at> porkrind.org>
To: "Jan D." <jan.h.d <at> swipnet.se>
Cc: 19850 <at> debbugs.gnu.org
Subject: Re: bug#19850: 25.0.50; [PATCH] configure.ac: Fix site-lisp
 paths with NS self-contained apps.
Date: Sat, 14 Feb 2015 02:09:50 -0800

[Message part 1 (text/plain, inline)]

On 2/14/15 1:25 AM, Jan D. wrote:
> 
> Also, /Library is in not the equivalent of /usr/local.  /usr/local is the equivalent of /usr/local.

Not really. /usr/local is for unix command liney stuff, which Emacs
isn't really a part of once it becomes a self contained .app.

> /Library is a system directory, a mix of /etc and /usr/share.  There are startup daemons there, fonts, internet plugins and so on.  These things are not in /usr/local on any sane Unix-like OS.

/Library is not really a system directory, though the system does
install stuff there by default. You're right that it's a bit of a mix,
but it's also definitely got /usr/local leanings as well. Apple says
this about it [1]:

> /Library (OS X only)—Apps that share resources between users store those resources in this version of the Library directory.

So it's certainly OK to put site wide application stuff in /Library
(given that it's Apple's stated purpose). And I believe it's technically
100% kosher to delete anything in there. Nothing in there is critical to
the system running. The Fonts that actually matter are in
/System/Library/Fonts. That's not really here nor there though (but it's
why I said it's "not really" a system directory).

The question is why should Emacs not default to a reasonable, user
controlled site-wide place? And where should that place be?

I think it's worthwhile to take a look at what Perl does, because it's
one of the more fitting-in-est unix programs the Mac ships with. The
built-in Perl modules are in /System/Library/Perl. If you run 'cpan' and
install modules yourself, they go into /Library/Perl. Tcl is similar.

So what I'm proposing is not without precedent...

I believe if a Mac user saw that /Library/Application Support/Emacs or
/Library/Emacs in the load-path, they would not bat an eye, and would
completely understand under what circumstances they would add stuff there.

On the other hand, there's a bit of asymmetry since the user's config is
still ~/.emacs and not ~/Library/Application Support/Emacs (and I
wouldn't want that to change). Even so, I still think /Library is the
right place to default locallisppath.

-David


[1]
https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1

[smime.p7s (application/pkcs7-signature, attachment)]

Previous Next

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