Should Emacs define site-lisp load-path for Dynamically-Loaded Modules?

Should Emacs define site-lisp load-path for Dynamically-Loaded Modules?

[Björn Bidar]

Hello,

Recently I have began on packaging Emacs packages for OpenSuSE Linux,
many of whom use dynamic modules.

I noticed that almost all packages that use dynamic modules compile
the module after installation and store it in the package directory.

Emacs define site-lisp for locally installed libraries however the
directory is usually contained inside <datadir>.

That makes me ask the questions should there be a second site-lisp for
dynamic modules in <libdir> by default?

Have a nice day,

Björn Bidar

Re: Should Emacs define site-lisp load-path for Dynamically-Loaded Modules?

[Alfred M. Szmidt]

   Recently I have began on packaging Emacs packages for OpenSuSE Linux,
   many of whom use dynamic modules.

   I noticed that almost all packages that use dynamic modules compile
   the module after installation and store it in the package directory.

   Emacs define site-lisp for locally installed libraries however the
   directory is usually contained inside <datadir>.

Might be a good idea to double check
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html .

The site-lisp directory can be read-only, and should only contain
architecture-_independent_ files since it sirts under datarootdir.

   That makes me ask the questions should there be a second site-lisp for
   dynamic modules in <libdir> by default?

Are they architecture-dependent?  Are they libraries or other object
files? Seems so, off the cuff sounds reasonable.

Re: Should Emacs define site-lisp load-path for Dynamically-Loaded Modules?

[Björn Bidar]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    Recently I have began on packaging Emacs packages for OpenSuSE Linux,
>    many of whom use dynamic modules.
>
>    I noticed that almost all packages that use dynamic modules compile
>    the module after installation and store it in the package directory.
>
>    Emacs define site-lisp for locally installed libraries however the
>    directory is usually contained inside <datadir>.
>
> Might be a good idea to double check
> https://www.gnu.org/prep/standards/html_node/Directory-Variables.html .
>
> The site-lisp directory can be read-only, and should only contain
> architecture-_independent_ files since it sirts under datarootdir.

The link you refer to doesn't contain any reference to site-lisp besides *lispdir*.
I thought it was clear that I don't mean to define site-lisp but define
a second site-lisp as you say your self.

>
>    That makes me ask the questions should there be a second site-lisp for
>    dynamic modules in <libdir> by default?
>
> Are they architecture-dependent?  Are they libraries or other object
> files? Seems so, off the cuff sounds reasonable.

Did you read the manual? Yes dynamic modules are per definition
architecture-dependent after they have been compiled as they use
compiled languages such as C or C++.

Re: Should Emacs define site-lisp load-path for Dynamically-Loaded Modules?

[Eli Zaretskii]

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Date: Tue, 26 Sep 2023 18:41:25 +0300
> 
> 
> Recently I have began on packaging Emacs packages for OpenSuSE Linux,
> many of whom use dynamic modules.
> 
> I noticed that almost all packages that use dynamic modules compile
> the module after installation and store it in the package directory.
> 
> Emacs define site-lisp for locally installed libraries however the
> directory is usually contained inside <datadir>.
> 
> That makes me ask the questions should there be a second site-lisp for
> dynamic modules in <libdir> by default?

Any rationale for doing that?  I mean, "should there be" is not really
a rationale...

We look for dynamic modules in the same directories as Lisp files for
2 reasons:

  . a dynamic module frequently comes with a part written in Lisp
    alongside the part written in C or some other language, so it
    makes sense to allow keeping these parts together;
  . dynamic modules are loaded by the 'load' primitive, so looking in
    the same directories makes loading easier to understand and use

So now the floor is yours to describe why would we want to add yet
another non-trivial complication into our loading process.

Re: Should Emacs define site-lisp load-path for Dynamically-Loaded Modules?

[Alfred M. Szmidt]

   The link you refer to doesn't contain any reference to site-lisp besides *lispdir*.
   I thought it was clear that I don't mean to define site-lisp but define
   a second site-lisp as you say your self.

site-lisp lives under datadir, hence the reference.

   >    That makes me ask the questions should there be a second site-lisp for
   >    dynamic modules in <libdir> by default?
   >
   > Are they architecture-dependent?  Are they libraries or other object
   > files? Seems so, off the cuff sounds reasonable.

   Did you read the manual?

I've read the manual many times, doesn't mean I remeber each thing in
it.  So please use a kinder tone, and assume that not everyone
remebers everything.

   Yes dynamic modules are per definition architecture-dependent after
   they have been compiled as they use compiled languages such as C or
   C++.

Re: Should Emacs define site-lisp load-path for Dynamically-Loaded Modules?

[Björn Bidar]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    The link you refer to doesn't contain any reference to site-lisp besides *lispdir*.
>    I thought it was clear that I don't mean to define site-lisp but define
>    a second site-lisp as you say your self.
>
> site-lisp lives under datadir, hence the reference.
>
>    >    That makes me ask the questions should there be a second site-lisp for
>    >    dynamic modules in <libdir> by default?
>    >
>    > Are they architecture-dependent?  Are they libraries or other object
>    > files? Seems so, off the cuff sounds reasonable.
>
>    Did you read the manual?
>
> I've read the manual many times, doesn't mean I remeber each thing in
> it.  So please use a kinder tone, and assume that not everyone
> remebers everything.
>
>    Yes dynamic modules are per definition architecture-dependent after
>    they have been compiled as they use compiled languages such as C or
>    C++.

Sorry for the tone it wasn't my intend to sound like this.

I assumed that the point was clear, maybe the name Dynamic modules isn't verbose enough.

Re: Should Emacs define site-lisp load-path for Dynamically-Loaded Modules?

[Björn Bidar]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Date: Tue, 26 Sep 2023 18:41:25 +0300
>> 
>> 
>> Recently I have began on packaging Emacs packages for OpenSuSE Linux,
>> many of whom use dynamic modules.
>> 
>> I noticed that almost all packages that use dynamic modules compile
>> the module after installation and store it in the package directory.
>> 
>> Emacs define site-lisp for locally installed libraries however the
>> directory is usually contained inside <datadir>.
>> 
>> That makes me ask the questions should there be a second site-lisp for
>> dynamic modules in <libdir> by default?
>
> Any rationale for doing that?  I mean, "should there be" is not really
> a rationale...
>
> We look for dynamic modules in the same directories as Lisp files for
> 2 reasons:
>
>   . a dynamic module frequently comes with a part written in Lisp
>     alongside the part written in C or some other language, so it
>     makes sense to allow keeping these parts together;
      Do we store the Emacs binary in the same directory as the lisp
      code (on every platform)?
      site-lisp as Alfred wrote is stored in datadir where only
      architecture independent code is allowed. The same is true for the
      Emacs Lisp provided by Emacs itself.
      The same reason why (native) compiled Emacs-Lisp is stored in
      lidir, while Emacs-Lisp or it's byte compiled variant is stored
      in datadir.
      

>   . dynamic modules are loaded by the 'load' primitive, so looking in
>     the same directories makes loading easier to understand and use
      the load primitive uses the load-path, adding another path to said
      path seems trivial to me.