bug#43475: closed (feature/native-comp; add a site-lisp path to comp-eln-load-path)

[GNU bug Tracking System]

Your message dated Mon, 05 Jun 2023 04:54:10 -0400
with message-id <yp1legycmrx.fsf@fencepost.gnu.org>
and subject line Re: bug#43475: feature/native-comp; add a site-lisp path to 
comp-eln-load-path
has caused the debbugs.gnu.org bug report #43475,
regarding feature/native-comp; add a site-lisp path to comp-eln-load-path
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
43475: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43475
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> feature/native-comp; add a site-lisp path to comp-eln-load-path
>
>
>
>
> Date: 
>
> Thu, 17 Sep 2020 13:37:04 -0400
>
>
>
>
> Hi Andrea,
>     Sorry for the delay getting this submitted. Here is a summary of the
> discussion about how to handle the site-lisp equivalent for eln files. Best!
> Tom
>
> Use case. We need a default convention for where eln files compile from
> files in /usr/share/emacs/site-lisp can be installed by a package manager.
> For the record, https://github.com/gentoo/gentoo/pull/16962 was the start
> of these discussions and the following devel thread is also relevant
> https://lists.gnu.org/archive/html/emacs-devel/2020-08/msg01036.html.
>
> My suggestion to use /usr/share was incorrect as Ulrich points out since
> /usr/share should never contain arch specific files. Thus, ${libdir}
> is the right base.
>
> Suggestions from the previous discussion are /usr/lib{,64}/emacs/site-eln and
> /usr/lib{,64}/emacs/site-lisp/eln.
>
> If we want to mirror the way native-lisp is used for the system files
> then ${libdir}/emacs/site-lisp and ${libdir}/emacs/site-lisp/native-lisp
> are two other options.
>
> I'm not sure the intervening native-lisp folder is necessary,
> especially given that
> there is the additional folder that is present for each version, and
> since the fact
> that we are in ${libdir}/emacs automatically suggests that we are dealing with
> native arch specific files. However, I suppose that there might be some future
> case where something other than the native-lisp files would be included in
> ${libdir}/emacs, so separating the eln files in their own folder would
> help. I have
> no idea how likely that happening in the future is though.
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#43475: feature/native-comp; add a site-lisp path to comp-eln-load-path
>
>
>
>
> Date: 
>
> Mon, 05 Jun 2023 04:54:10 -0400
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13)
>
>
>
>
> Ulrich Mueller <ulm@gentoo.org> writes:
>
> >>>>>> On Fri, 18 Sep 2020, Andrea Corallo wrote:
> >
> >> Tom Gillespie <tgbugs@gmail.com> writes:
> >
> >>> Suggestions from the previous discussion are
> >>> /usr/lib{,64}/emacs/site-eln and /usr/lib{,64}/emacs/site-lisp/eln.
> >>> 
> >>> If we want to mirror the way native-lisp is used for the system files
> >>> then ${libdir}/emacs/site-lisp and ${libdir}/emacs/site-lisp/native-lisp
> >>> are two other options.
> >
> >> I think ${libdir}/emacs/site-lisp/native-lisp would be probably more
> >> future proof but I've no strong preference.
> >
> >> Ulrich what would be your suggestion for this?
> >
> > I'd prefer the shorter path. I believe it's very unlikely that there
> > could be other files in future that would be both lisp and architecture
> > dependent, i.e. that would be installed in ${libdir}/emacs/site-lisp/
> > as well. In other words, the additional subdirectory level would be
> > totally redundant.
> >
> > So, my suggestion would be either ${libdir}/emacs/site-lisp/ or
> > ${libdir}/emacs/site-eln/ with a slight preference for the second.
> >
> > (Note that Gentoo would create another subdirectory when installing an
> > add-on elisp package, so the path would be (for example)
> > ${libdir}/emacs/site-eln/${package_name}/.)
>
> Closing this very old bug still related to feature/native-comp as I
> think ATM the interface we provide satisfies distro needs.  Happy to
> reopen if more work is needed in this area.
>
> Best Regards
>
>   Andrea
>
>
> --- End Message ---