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

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

[David Caldwell]

[-- Attachment #1.1: Type: text/plain, Size: 1601 bytes --]


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@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

[-- Attachment #1.2: mac-site-lisp-path.patch --]
[-- Type: text/plain, Size: 914 bytes --]

From c20e8816f3905fa3ec6f82a7f566f7ce32dc178b Mon Sep 17 00:00:00 2001
From: David Caldwell <david@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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

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

[Jan D.]

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@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@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>

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

[David Caldwell]

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

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

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

[Jan D.]

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.

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

[Jan D.]

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

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

	Jan D.

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

[Jan D.]

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

	Jan D.

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

[David Caldwell]

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

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



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

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

[Jan D.]

> 13 feb 2015 kl. 20:41 skrev David Caldwell <david@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.

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

[David Caldwell]

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

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]