Retrieving the "include" directory for Emacs Modules

Retrieving the "include" directory for Emacs Modules

[Marco Antoniotti]

Hi

To compile Emacs C modules we need the proper 'include' directory.  I.e.,
we need to stick that information into Makefiles.

We do have lisp-directory (and we can surmise the location of the include
directory from it), but it would be nice to have something like
em-include-directory (the em- prefix for "Emacs Module").

Meanwhile, any idea about how to make this somewhat portable?

Any idea?

-- 
Marco Antoniotti
Somewhere over the Rainbow

Re: Retrieving the "include" directory for Emacs Modules

[Eli Zaretskii]

> From: Marco Antoniotti <marcoxa@gmail.com>
> Date: Sat, 7 Dec 2024 17:27:16 +0100
> 
> To compile Emacs C modules we need the proper 'include' directory.  I.e.,
> we need to stick that information into Makefiles.
> 
> We do have lisp-directory (and we can surmise the location of the include
> directory from it), but it would be nice to have something like
> em-include-directory (the em- prefix for "Emacs Module").

Isn't that

  (expand-file-name "../../../include" data-directory)

?

Re: Retrieving the "include" directory for Emacs Modules

[Björn Bidar]

Marco Antoniotti <marcoxa@gmail.com> writes:

> Hi
>
> To compile Emacs C modules we need the proper 'include' directory.  I.e.,
> we need to stick that information into Makefiles.
>
> We do have lisp-directory (and we can surmise the location of the include
> directory from it), but it would be nice to have something like
> em-include-directory (the em- prefix for "Emacs Module").
>
> Meanwhile, any idea about how to make this somewhat portable?

You mean in the makefile or in lisp? If it's in the makefile
you should find out the directory the makefile is in and then go from
there.

E.g.:

MAKEFILEDIR := $(dir $(realpath $(lastword $(MAKEFILE_LIST))))

CFLAGS += -I$(MAKEFILEDIR)/include

Re: Retrieving the "include" directory for Emacs Modules

[Eli Zaretskii]

> From: Marco Antoniotti <marcoxa@gmail.com>
> Date: Sun, 8 Dec 2024 10:59:28 +0100
> 
> Sorry Eli
> 
> your solution is not portable and it doesn't work on Mac and Windows (29.2)
> 
> On Mac the following works
> 
> ELISP> (expand-file-name "../include" data-directory)
> "/Applications/Emacs.app/Contents/Resources/include"
> 
> On Windows the include folder is "higher" up.
> "C:\Program Files\Emacs\emacs-29.2\include\"

Sorry, I used too few "..".  The correct way is

  (expand-file-name "../../../../include" data-directory)

> Given that people (like me) are experimenting with emacs modules, I'd lobby
> for the introduction of a 'include-direcotry' variable.

I honestly don't understand why you need this at all.  emacs-module.h
is supposed to be installed in the compilers include tree, where the
compiler looks for header files by default.  So you shouldn't even
need to know where the header lives, in order to compile a module.
The module's code should just do

  #include <emacs-module.h>

and that's it.  Or what am I missing?

Re: Retrieving the "include" directory for Emacs Modules

[Stefan Monnier via Users list for the GNU Emacs text editor]

> I honestly don't understand why you need this at all.  emacs-module.h
> is supposed to be installed in the compilers include tree, where the
> compiler looks for header files by default.  So you shouldn't even
> need to know where the header lives, in order to compile a module.
> The module's code should just do
>
>   #include <emacs-module.h>
>
> and that's it.  Or what am I missing?

That presumes that Emacs is installed system-wide (and "properly").
When the compilation of the module is initiated from within Emacs, it
would make a lot of sense for this "ambient" Emacs to be able to tell
`make/gcc/younameit` explicitly and reliably where its own
`emacs-module.h` can be found.


        Stefan

Re: Retrieving the "include" directory for Emacs Modules

[Stefan Monnier via Users list for the GNU Emacs text editor]

> EMACS_INCLUDE_DIR := $(shell $(EMACS) -q --batch --eval "(princ
> *em-include-directory*)")
> EMACS_SRC_DIR := $(shell $(EMACS) -q --batch --eval "(princ
> *em-scr-directory*)")

FWIW, when compiled from within Emacs, you'd be better served with
something like:

    (call-process "make" nil nil nil
                  (concat "EMACS_INCLUDE_DIR=" em-include-directory))


- Stefan

Re: Retrieving the "include" directory for Emacs Modules

[Eli Zaretskii]

> From: Marco Antoniotti <marcoxa@gmail.com>
> Date: Sun, 8 Dec 2024 16:18:15 +0100
> 
> sorry again: the behavior on Mac and Windows is different w.r.t.
> data-directory (see previous message).  I can try on a Linux machine
> tomorrow.  Note that I installed Emacs with brew on my Mac
> 
> Case in point: if I try to install 'pq' from the package manager I get the
> following error.
> 
> gcc -I/Users/marcoxa/.emacs.d/elpa/pq-0.2 -I -I/usr/share/emacs/29.4
> -I/usr/local/include/postgresql@14 -std=gnu99 -ggdb3 -Wall -fPIC -c
> pq-core.c
> 
> pq-core.c:19:10: fatal error: 'emacs-module.h' file not found
>    19 | #include <emacs-module.h>
>       |          ^~~~~~~~~~~~~~~~
> 1 error generated.
> make: *** [pq-core.o] Error 1
> 
> which is not surprising as the include directory is not listed in the -I
> options.

It shouldn't be: if the compiler cannot find emacs-module.h, then your
Emacs is installed incorrectly.  The installation should put
emacs-module.h where the compiler looks for include files.

> Of course, I can muck around and ensure that the C_INCLUDE_PATH has the
> right things in it, but the issue, as is, IMHO remains.

You shouldn't need to mess with C_INCLUDE_PATH, because emacs-module.h
is supposed to be in the C include path to begin with.

> Having said that, another reason for needing a reliable
> include-directory variable,
> is to query Emacs in batch mode (I know: iti is expensive), to run a build
> system outside Emacs for testing.

Sorry, I don't understand that: what do you mean by "to run a build
system"?

Re: Retrieving the "include" directory for Emacs Modules

[Eli Zaretskii]

> From: Marco Antoniotti <marcoxa@gmail.com>
> Date: Sun, 8 Dec 2024 16:36:09 +0100
> 
> I have no qualms about being able to "fix" 'pq' to make it work.
> 
> But I am writing an Emacs Module and I do not want to force anybody to
> "fix" my setup ("It works on my machine" (tm))
> 
> In other words, I would like to be able to write
> 
> EMACS_INCLUDE_DIR := $(shell $(EMACS) -q --batch --eval "(princ
> *em-include-directory*)")
> EMACS_SRC_DIR := $(shell $(EMACS) -q --batch --eval "(princ
> *em-scr-directory*)")

Once again: if your Emacs is installed correctly, emacs-module.h
should be in a directory where the C compiler looks by default for its
header files.  No -I command-line options should be needed.  Just make
sure to put emacs-module.h where you have stdio.h and other standard
headers.

Re: Retrieving the "include" directory for Emacs Modules

[Eli Zaretskii]

> Date: Sun, 08 Dec 2024 10:47:54 -0500
> From:  Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> > I honestly don't understand why you need this at all.  emacs-module.h
> > is supposed to be installed in the compilers include tree, where the
> > compiler looks for header files by default.  So you shouldn't even
> > need to know where the header lives, in order to compile a module.
> > The module's code should just do
> >
> >   #include <emacs-module.h>
> >
> > and that's it.  Or what am I missing?
> 
> That presumes that Emacs is installed system-wide (and "properly").

What other way is there to install Emacs?

> When the compilation of the module is initiated from within Emacs, it
> would make a lot of sense for this "ambient" Emacs to be able to tell
> `make/gcc/younameit` explicitly and reliably where its own
> `emacs-module.h` can be found.

But if Emacs is "not installed properly", we don't know that.

Re: Retrieving the "include" directory for Emacs Modules

[Stefan Monnier via Users list for the GNU Emacs text editor]

>> > I honestly don't understand why you need this at all.  emacs-module.h
>> > is supposed to be installed in the compilers include tree, where the
>> > compiler looks for header files by default.  So you shouldn't even
>> > need to know where the header lives, in order to compile a module.
>> > The module's code should just do
>> >
>> >   #include <emacs-module.h>
>> >
>> > and that's it.  Or what am I missing?
>> 
>> That presumes that Emacs is installed system-wide (and "properly").
>
> What other way is there to install Emacs?

Compile manually and run from the build tree?
Uncompress a downloaded pre-compiled archive into a directory and just
use it from there (AFAIK, very common under macOS and Windows)?
With luck on some systems the C (or other) compiler is installed in
a similar way (i.e. in its own subdirectory, siloed from Emacs).

>> When the compilation of the module is initiated from within Emacs, it
>> would make a lot of sense for this "ambient" Emacs to be able to tell
>> `make/gcc/younameit` explicitly and reliably where its own
>> `emacs-module.h` can be found.
> But if Emacs is "not installed properly", we don't know that.

Emacs *should* know that, just like it knows where is its
`lisp-directory`.


        Stefan

Re: Retrieving the "include" directory for Emacs Modules

[Eli Zaretskii]

> Date: Sun, 08 Dec 2024 11:48:24 -0500
> From:  Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> >> >   #include <emacs-module.h>
> >> >
> >> > and that's it.  Or what am I missing?
> >> 
> >> That presumes that Emacs is installed system-wide (and "properly").
> >
> > What other way is there to install Emacs?
> 
> Compile manually and run from the build tree?

That's called "run uninstalled".  And in that case, the user who does
that knows very well where the header lives: in the same directory
from which he/she runs Emacs.

> Uncompress a downloaded pre-compiled archive into a directory and just
> use it from there (AFAIK, very common under macOS and Windows)?

If that doesn't place emacs-module.h in the system-wide include
directory, it is a broken installation.

> With luck on some systems the C (or other) compiler is installed in
> a similar way (i.e. in its own subdirectory, siloed from Emacs).

That's not how multi-package installation should be organized if the
user wants the packages to cooperate.

> >> When the compilation of the module is initiated from within Emacs, it
> >> would make a lot of sense for this "ambient" Emacs to be able to tell
> >> `make/gcc/younameit` explicitly and reliably where its own
> >> `emacs-module.h` can be found.
> > But if Emacs is "not installed properly", we don't know that.
> 
> Emacs *should* know that, just like it knows where is its
> `lisp-directory`.

That's impractical expectation.  Recall how hard we worked to find the
pdumper file and the preloaded *.eln files, what with all the tricks
people use when installing Emacs.  I'm not interested in adding
another burden to our maintenance so that Emacs will paper over broken
installations.  Sorry.

Re: Retrieving the "include" directory for Emacs Modules

[Marco Antoniotti]

Hi Eli

somewhere, somehow (don't ask me), the "data" directory where emacs keeps
its stuff is created and its location recorded.

The emacs-module.h is the only thing that sits in the include directory.

Now.  On my Windows machine, where I install Emacs downloading the
installer from one of the links available on the main website, the
installation seems, AFAIK, to be up to your standards.

On my Mac, If I install emacs as a "formula" (i.e., not a s an app) things
seem installed as they should be.  OTOH the brew "cask" (which installs a
.app in the Application directory) seems to create something that Apple
likes, but that STILL may be told to have a pointer to the include
directory as it does to the data-directory.

This is obviously something that the brew folks should deal with, but the
notion of having a variable that tracks the include directory still has
merit.  At least as an extra guideline to people like the brew maintainers.

All the best

Marco









On Sun, Dec 8, 2024 at 8:45 PM <help-gnu-emacs-request@gnu.org> wrote:

> Send help-gnu-emacs mailing list submissions to
>         help-gnu-emacs@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/help-gnu-emacs
> or, via email, send a message with subject or body 'help' to
>         help-gnu-emacs-request@gnu.org
>
> You can reach the person managing the list at
>         help-gnu-emacs-owner@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of help-gnu-emacs digest..."
>
>
> Today's Topics:
>
>    1. Re: Retrieving the "include" directory for Emacs Modules
>       (Eli Zaretskii)
>    2. Re: Unicode and text editors (Heime)
>    3. Re: Unicode and text editors (Eli Zaretskii)
>    4. Re: Unicode and text editors (Heime)
>    5. Re: Unicode and text editors (Eli Zaretskii)
>    6. Re: Checking conditions unrelated to expression
>       (Michael Heerdegen)
>    7. Re: Unicode and text editors (Heime)
>    8. Re: Transforming paths in compilation output (containerized
>       builds) (Björn Bidar)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 08 Dec 2024 19:46:11 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Retrieving the "include" directory for Emacs Modules
> Message-ID: <865xnuf4po.fsf@gnu.org>
>
> > Date: Sun, 08 Dec 2024 11:48:24 -0500
> > From:  Stefan Monnier via Users list for the GNU Emacs text editor <
> help-gnu-emacs@gnu.org>
> >
> > >> >   #include <emacs-module.h>
> > >> >
> > >> > and that's it.  Or what am I missing?
> > >>
> > >> That presumes that Emacs is installed system-wide (and "properly").
> > >
> > > What other way is there to install Emacs?
> >
> > Compile manually and run from the build tree?
>
> That's called "run uninstalled".  And in that case, the user who does
> that knows very well where the header lives: in the same directory
> from which he/she runs Emacs.
>
> > Uncompress a downloaded pre-compiled archive into a directory and just
> > use it from there (AFAIK, very common under macOS and Windows)?
>
> If that doesn't place emacs-module.h in the system-wide include
> directory, it is a broken installation.
>
> > With luck on some systems the C (or other) compiler is installed in
> > a similar way (i.e. in its own subdirectory, siloed from Emacs).
>
> That's not how multi-package installation should be organized if the
> user wants the packages to cooperate.
>
> > >> When the compilation of the module is initiated from within Emacs, it
> > >> would make a lot of sense for this "ambient" Emacs to be able to tell
> > >> `make/gcc/younameit` explicitly and reliably where its own
> > >> `emacs-module.h` can be found.
> > > But if Emacs is "not installed properly", we don't know that.
> >
> > Emacs *should* know that, just like it knows where is its
> > `lisp-directory`.
>
> That's impractical expectation.  Recall how hard we worked to find the
> pdumper file and the preloaded *.eln files, what with all the tricks
> people use when installing Emacs.  I'm not interested in adding
> another burden to our maintenance so that Emacs will paper over broken
> installations.  Sorry.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 08 Dec 2024 17:54:43 +0000
> From: Heime <heimeborgia@protonmail.com>
> To: Eli Zaretskii <eliz@gnu.org>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Unicode and text editors
> Message-ID:
>
> <VpTsRgeCxJL-JNeghs40Qt5cLBHbFykIIGYBA6zMT8AkgKUGc_RobIkWbXrtJnf4MVOF_oHrD4iCYJk1jS92lbFA2SjCpB_1htjcPAV0gv0=@
> protonmail.com>
>
> Content-Type: text/plain; charset=utf-8
>
>
> On Monday, December 9th, 2024 at 4:32 AM, Eli Zaretskii <eliz@gnu.org>
> wrote:
>
> > > Date: Sun, 08 Dec 2024 15:15:31 +0000
> > > From: "W. Greenhouse" via Users list for the GNU Emacs text editor
> help-gnu-emacs@gnu.org
> > >
> > > Heime via Users list for the GNU Emacs text editor
> > > help-gnu-emacs@gnu.org writes:
> > >
> > > > Is this becoming the norm? What about emacs?
> > > >
> > > > Does emacs encourage use of unicode characters (UTF-8) in code
> comments
> > > > and documentation?
> > >
> > > UTF-8 represents Emacs' internal text encoding
> >
> >
> > No, the internal encoding is different (it's a superset of UTF-8).
> >
> > > and also its default preference for new files.
> >
> >
> > That is only true if the user's locale has UTF-8 as its codeset.
> >
> > > When visiting existing files it attempts to
> > > detect the encoding, and maintain it while editing.
> >
> > That is correct.
>
> Does this mean that we should not worry when we use UTF-8?   Would
> UTF-* be supported, and detected.  With the appropriate symbols showing
> as they should.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 08 Dec 2024 20:44:42 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Unicode and text editors
> Message-ID: <861pyif205.fsf@gnu.org>
>
> > Date: Sun, 08 Dec 2024 17:54:43 +0000
> > From: Heime <heimeborgia@protonmail.com>
> > Cc: help-gnu-emacs@gnu.org
> >
> > > > When visiting existing files it attempts to
> > > > detect the encoding, and maintain it while editing.
> > >
> > > That is correct.
> >
> > Does this mean that we should not worry when we use UTF-8?   Would
> > UTF-* be supported, and detected.  With the appropriate symbols showing
> > as they should.
>
> I was talking about Emacs.  Your original question was about other
> editors.  I'm not familiar with other modern editors enough to tell
> whether you should or should not worry.  In particular, I don't know
> how they recognize UTF-8, and am not sure that Emacs coding cookies
> are supported by them.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 08 Dec 2024 18:55:52 +0000
> From: Heime <heimeborgia@protonmail.com>
> To: Eli Zaretskii <eliz@gnu.org>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Unicode and text editors
> Message-ID:
>
> <p6vv68VE9KE4Y8ML-nAfy75EPmsnsFPaRGtZglz_qmAeKRH62jOOy9XqbeinPnf0-5GkV3BhYTB2gR6QAV_YA85x5teM-wfdi5SXLgsW4W4=@
> protonmail.com>
>
> Content-Type: text/plain; charset=utf-8
>
>
>
>
>
>
> Sent with Proton Mail secure email.
>
> On Monday, December 9th, 2024 at 6:44 AM, Eli Zaretskii <eliz@gnu.org>
> wrote:
>
> > > Date: Sun, 08 Dec 2024 17:54:43 +0000
> > > From: Heime heimeborgia@protonmail.com
> > > Cc: help-gnu-emacs@gnu.org
> > >
> > > > > When visiting existing files it attempts to
> > > > > detect the encoding, and maintain it while editing.
> > > >
> > > > That is correct.
> > >
> > > Does this mean that we should not worry when we use UTF-8? Would
> > > UTF-* be supported, and detected. With the appropriate symbols showing
> > > as they should.
> >
> >
> > I was talking about Emacs. Your original question was about other
> > editors. I'm not familiar with other modern editors enough to tell
> > whether you should or should not worry. In particular, I don't know
> > how they recognize UTF-8, and am not sure that Emacs coding cookies
> > are supported by them.
>
> Is it reasonable to expect that UTF-* characters are recognised and
> supported?
> What is your school of thought regarding emacs?
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 08 Dec 2024 21:07:47 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Unicode and text editors
> Message-ID: <86wmgadmd8.fsf@gnu.org>
>
> > Date: Sun, 08 Dec 2024 18:55:52 +0000
> > From: Heime <heimeborgia@protonmail.com>
> > Cc: help-gnu-emacs@gnu.org
> >
> > > I was talking about Emacs. Your original question was about other
> > > editors. I'm not familiar with other modern editors enough to tell
> > > whether you should or should not worry. In particular, I don't know
> > > how they recognize UTF-8, and am not sure that Emacs coding cookies
> > > are supported by them.
> >
> > Is it reasonable to expect that UTF-* characters are recognised and
> supported?
>
> Reasonable? yes.  But the problem is not trivial: Emacs itself not
> always recognizes UTF-8 reliably.  So there could be problems.
>
> > What is your school of thought regarding emacs?
>
> I don't understand the question, sorry.
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 08 Dec 2024 20:19:57 +0100
> From: Michael Heerdegen <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Checking conditions unrelated to expression
> Message-ID: <87ikruouci.fsf@web.de>
> Content-Type: text/plain
>
> Hello,
>
> the only thing I want to add to Stefan's answer: the 'let' pattern can
> be (despite the name) used as a full-featured "sub-pcase".  But also see
> 'app' etc. - just see the pattern descriptions in the fine docs.
>
> Michael.
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 08 Dec 2024 19:39:55 +0000
> From: Heime <heimeborgia@protonmail.com>
> To: Eli Zaretskii <eliz@gnu.org>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Unicode and text editors
> Message-ID:
>
> <Be0XIegjOn-QFIHzjODCIV_jnl-68E45AFCdDLeqeQ6cYw8sH6hMgQudQVXE_Jx4REYEV96IgFMaEtOaIlDTWDY7QbsIDrY61z-feuEjIpM=@
> protonmail.com>
>
> Content-Type: text/plain; charset=utf-8
>
>
> On Monday, December 9th, 2024 at 7:07 AM, Eli Zaretskii <eliz@gnu.org>
> wrote:
>
> > > Date: Sun, 08 Dec 2024 18:55:52 +0000
> > > From: Heime heimeborgia@protonmail.com
> > > Cc: help-gnu-emacs@gnu.org
> > >
> > > > I was talking about Emacs. Your original question was about other
> > > > editors. I'm not familiar with other modern editors enough to tell
> > > > whether you should or should not worry. In particular, I don't know
> > > > how they recognize UTF-8, and am not sure that Emacs coding cookies
> > > > are supported by them.
> > >
> > > Is it reasonable to expect that UTF-* characters are recognised and
> supported?
> >
> >
> > Reasonable? yes. But the problem is not trivial: Emacs itself not
> > always recognizes UTF-8 reliably. So there could be problems.
> >
> > > What is your school of thought regarding emacs?
> >
> >
> > I don't understand the question, sorry.
>
> Should we comfortable use UTF Characters in source code when using Emacs?
> When there are problems, do they usually get looked into and fixed if
> possible?
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Sun, 08 Dec 2024 21:45:15 +0200
> From: Björn Bidar <bjorn.bidar@thaodan.de>
> To: Yuri Khan <yuri.v.khan@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  help-gnu-emacs@gnu.org
> Subject: Re: Transforming paths in compilation output (containerized
>         builds)
> Message-ID: <87frmy2c38.fsf@>
> Content-Type: text/plain
>
> Yuri Khan <yuri.v.khan@gmail.com> writes:
>
> > On Sun, 8 Dec 2024 at 12:43, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> > > Is compilation-transform-file-match-alist what you are looking for?
> >> >
> >> > The variable talks only about errors. Does it apply to all messages
> not just
> >> > the errors?
> >>
> >> It is applied to all messages.
> >
> > In my experience, it is not applied to messages as such. It is
> > consulted when building text properties while fontifying the messages
> > so that the user can jump to error locations; but the actual visible
> > text in the buffer remains unmodified.
>
> That the actual text remains unmodified is good, it's actually better
> since it doesn't reveal any private information/makes the output depend on
> the
> users machine.
>
> As long as it applies to all messages it's good. Maybe the description
> or the name of the variable should be changed then.
>
> I looked at the integration for the other container engines for
> inspiration on how to solve this issue.
> None of them handle this issue or are affected.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> help-gnu-emacs mailing list
> help-gnu-emacs@gnu.org
> https://lists.gnu.org/mailman/listinfo/help-gnu-emacs
>
>
> ------------------------------
>
> End of help-gnu-emacs Digest, Vol 265, Issue 40
> ***********************************************
>


-- 
Marco Antoniotti
Somewhere over the Rainbow

Re: Retrieving the "include" directory for Emacs Modules

[Stefan Monnier via Users list for the GNU Emacs text editor]

>> Compile manually and run from the build tree?
> That's called "run uninstalled".  And in that case, the user who does
> that knows very well where the header lives: in the same directory
> from which he/she runs Emacs.

Why would they know that?  I mean, of course, some will, but many people
compile their own Emacs just to live on the bleeding edge and may never
really look at the C code.

[ Personally, I knew that *an* `emacs-module.h` file lived in there, but
  I wasn't 100% sure it's the right one to use (I expected there might
  be another one in some other directory).  ]

>> Uncompress a downloaded pre-compiled archive into a directory and just
>> use it from there (AFAIK, very common under macOS and Windows)?
> If that doesn't place emacs-module.h in the system-wide include
> directory, it is a broken installation.

If the user doesn't have administrator rights, then the installation
can't really be blamed for not adding itself to a system-wide
include directory.

>> Emacs *should* know that, just like it knows where is its
>> `lisp-directory`.
> That's impractical expectation.

We decide where the .h file is put, so it's really not.

> Recall how hard we worked to find the pdumper file and the preloaded
> *.eln files, what with all the tricks people use when
> installing Emacs.

Yup.  And we don't need anything *more*.  We just need to place the
include file at a place that's easy to find once we know the rest.
E.g. it could be `$(data-directory)/module-include`.

> I'm not interested in adding another burden to our maintenance so that
> Emacs will paper over broken installations.

The system-wide install may have an older version of Emacs than the one
from which we want to compile a module.

It's good that we expose `emacs-module.h` system-wide, but I think it's
even more important for Emacs to be able to compile its own modules
without having to rely on that.


        Stefan

Re: Retrieving the "include" directory for Emacs Modules

[Eli Zaretskii]

> From: Marco Antoniotti <marcoxa@gmail.com>
> Date: Mon, 9 Dec 2024 10:58:57 +0100
> 
> On my Mac, If I install emacs as a "formula" (i.e., not a s an app) things
> seem installed as they should be.  OTOH the brew "cask" (which installs a
> .app in the Application directory) seems to create something that Apple
> likes, but that STILL may be told to have a pointer to the include
> directory as it does to the data-directory.
> 
> This is obviously something that the brew folks should deal with, but the
> notion of having a variable that tracks the include directory still has
> merit.  At least as an extra guideline to people like the brew maintainers.

As I tried to explain, if emacs-module.h is not installed in its
intended place, we cannot know where it is installed.  We only know
that from the default installation locations we have in our Makefiles,
but if some distros modify that, we cannot know.

And I still contend that the correct installation should put this file
where all the other header files are, and then the compiler will
always find it.  Users who don't want to fight the uphill battle
against brew could simply copy the file to the compiler's include
directory, and be done.

Re: Retrieving the "include" directory for Emacs Modules

[Rudolf Schlatte]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Marco Antoniotti <marcoxa@gmail.com>
>> Date: Mon, 9 Dec 2024 10:58:57 +0100
>> 
>> On my Mac, If I install emacs as a "formula" (i.e., not a s an app) things
>> seem installed as they should be.  OTOH the brew "cask" (which installs a
>> .app in the Application directory) seems to create something that Apple
>> likes, but that STILL may be told to have a pointer to the include
>> directory as it does to the data-directory.
>> 
>> This is obviously something that the brew folks should deal with, but the
>> notion of having a variable that tracks the include directory still has
>> merit.  At least as an extra guideline to people like the brew maintainers.
>
> As I tried to explain, if emacs-module.h is not installed in its
> intended place, we cannot know where it is installed.  We only know
> that from the default installation locations we have in our Makefiles,
> but if some distros modify that, we cannot know.
>
> And I still contend that the correct installation should put this file
> where all the other header files are, and then the compiler will
> always find it.  Users who don't want to fight the uphill battle
> against brew could simply copy the file to the compiler's include
> directory, and be done.

`make install' for the nextstep backend produces Emacs.app, a
self-contained bundle that can be double-clicked to start Emacs but is
also a directory that contains the standard Emacs files inside, as
Emacs.app/Contents/Resources/{etc,include,info,lisp,man,site-lisp,...}.

I guess this is the case that Marco encounters: C-h N opens
<wherever>/Emacs.app/Contents/Resources/etc/NEWS, so the running Emacs
must have some knowledge about where it is installed.

Re: Retrieving the "include" directory for Emacs Modules

[Stefan Monnier via Users list for the GNU Emacs text editor]

> As I tried to explain, if emacs-module.h is not installed in its
> intended place, we cannot know where it is installed.

The patch below would make sure that `emacs-module.h` is always
available at `$(data-directory)/include/emacs-module.h`.


        Stefan


diff --git a/src/Makefile.in b/src/Makefile.in
index c278924ef94..c1385dd7188 100644
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -731,12 +731,19 @@ MAKE_PDUMPER_FINGERPRINT =
 MAKE_PDUMPER_FINGERPRINT =
 endif
 
+modules_header = $(top_srcdir)/etc/include/emacs-module.h
+
+$(modules_header): $(srcdir)/emacs-module.h
+	$(AM_V_at)$(MKDIR_P) $(dir $@)
+	$(AM_V_at)cp $< $@
+
 ## We have to create $(etc) here because init_cmdargs tests its
 ## existence when setting Vinstallation_directory (FIXME?).
 ## This goes on to affect various things, and the emacs binary fails
 ## to start if Vinstallation_directory has the wrong value.
 temacs$(EXEEXT): $(LIBXMENU) $(ALLOBJS) $(LIBEGNU_ARCHIVE) $(EMACSRES) \
-  $(charsets) $(charscript) ${emoji-zwj} $(MAKE_PDUMPER_FINGERPRINT)
+  $(charsets) $(charscript) ${emoji-zwj} $(MAKE_PDUMPER_FINGERPRINT)   \
+  $(modules_header)
 ifeq ($(HAVE_BE_APP),yes)
 	$(AM_V_CXXLD)$(CXX) -o $@.tmp \
 	  $(ALL_CFLAGS) $(TEMACS_LDFLAGS) $(LDFLAGS) \

Re: Retrieving the "include" directory for Emacs Modules

[Eli Zaretskii]

> Date: Mon, 09 Dec 2024 17:10:50 -0500
> From:  Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> > As I tried to explain, if emacs-module.h is not installed in its
> > intended place, we cannot know where it is installed.
> 
> The patch below would make sure that `emacs-module.h` is always
> available at `$(data-directory)/include/emacs-module.h`.

Sorry, this is wrong.  No compiler will look in that directory without
a suitable -I option, so this is a change that will break previous
(and correct) behavior.

Re: Retrieving the "include" directory for Emacs Modules

[Stefan Monnier via Users list for the GNU Emacs text editor]

>> > As I tried to explain, if emacs-module.h is not installed in its
>> > intended place, we cannot know where it is installed.
>> The patch below would make sure that `emacs-module.h` is always
>> available at `$(data-directory)/include/emacs-module.h`.
> Sorry, this is wrong. [...] this is a change that will break previous
> (and correct) behavior.

I don't see how it would break anything: the .h file is still *also*
copied to the $(includedir) for those people who want to compile their
module outside of Emacs.

> No compiler will look in that directory without a suitable -I option,

That's OK: the sole purpose of the change is to let ELPA packages call
`gcc` with such a `-I`!


        Stefan

Re: Retrieving the "include" directory for Emacs Modules

[Eli Zaretskii]

> Date: Tue, 10 Dec 2024 22:23:05 -0500
> From:  Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> >> > As I tried to explain, if emacs-module.h is not installed in its
> >> > intended place, we cannot know where it is installed.
> >> The patch below would make sure that `emacs-module.h` is always
> >> available at `$(data-directory)/include/emacs-module.h`.
> > Sorry, this is wrong. [...] this is a change that will break previous
> > (and correct) behavior.
> 
> I don't see how it would break anything: the .h file is still *also*
> copied to the $(includedir) for those people who want to compile their
> module outside of Emacs.

That makes this easier to accept, but there are still issues.

> > No compiler will look in that directory without a suitable -I option,
> 
> That's OK: the sole purpose of the change is to let ELPA packages call
> `gcc` with such a `-I`!

Let's discuss this in a proper place, not here, okay?  In particular,
I'd like to hear more opinions and data points, from people who don't
necessarily read this forum.

Re: Retrieving the "include" directory for Emacs Modules

[Marco Antoniotti]

Hi Eli

What would be a proper place?

Marco



On Wed, Dec 11, 2024 at 6:03 PM <help-gnu-emacs-request@gnu.org> wrote:

> Send help-gnu-emacs mailing list submissions to
>         help-gnu-emacs@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/help-gnu-emacs
> or, via email, send a message with subject or body 'help' to
>         help-gnu-emacs-request@gnu.org
>
> You can reach the person managing the list at
>         help-gnu-emacs-owner@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of help-gnu-emacs digest..."
>
>
> Today's Topics:
>
>    1. Re: Retrieving the "include" directory for Emacs Modules
>       (Eli Zaretskii)
>    2. Why does saving a buffer to a new file clear local variables?
>       (Patrick Nicodemus)
>    3. Gnus: Permanently killing a thread? (Christopher Howard)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 11 Dec 2024 15:01:44 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Retrieving the "include" directory for Emacs Modules
> Message-ID: <86bjxi4blz.fsf@gnu.org>
>
> > Date: Tue, 10 Dec 2024 22:23:05 -0500
> > From:  Stefan Monnier via Users list for the GNU Emacs text editor <
> help-gnu-emacs@gnu.org>
> >
> > >> > As I tried to explain, if emacs-module.h is not installed in its
> > >> > intended place, we cannot know where it is installed.
> > >> The patch below would make sure that `emacs-module.h` is always
> > >> available at `$(data-directory)/include/emacs-module.h`.
> > > Sorry, this is wrong. [...] this is a change that will break previous
> > > (and correct) behavior.
> >
> > I don't see how it would break anything: the .h file is still *also*
> > copied to the $(includedir) for those people who want to compile their
> > module outside of Emacs.
>
> That makes this easier to accept, but there are still issues.
>
> > > No compiler will look in that directory without a suitable -I option,
> >
> > That's OK: the sole purpose of the change is to let ELPA packages call
> > `gcc` with such a `-I`!
>
> Let's discuss this in a proper place, not here, okay?  In particular,
> I'd like to hear more opinions and data points, from people who don't
> necessarily read this forum.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 10 Dec 2024 23:05:00 -0500
> From: Patrick Nicodemus <gadget142@gmail.com>
> To: help-gnu-emacs@gnu.org
> Subject: Why does saving a buffer to a new file clear local variables?
> Message-ID:
>         <CADZEZBZbKRo7uHpqjOBTADhQcUG5U=
> H+RuZOOwd7DRdtLE_s5A@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> If I create a new buffer like (get-buffer-create "tmpbuf"),
> switch to the buffer, and execute the commands
> (make-variable-buffer-local "abc")
> (setq abc 3)
> and then save the buffer to, say, "tmpbuf", then abc becomes nil.
> Why is this the case?
> Is this behavior documented anywhere?
> I checked that it doesn't change the major mode. It is "Fundamental" before
> and after saving.
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 11 Dec 2024 07:52:38 -0900
> From: Christopher Howard <christopher@librehacker.com>
> To: Help Gnu Emacs Mailing List <help-gnu-emacs@gnu.org>
> Subject: Gnus: Permanently killing a thread?
> Message-ID: <87ldwmgo15.fsf@librehacker.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi, in Gnus I frequently use gnus-summary-kill-same-subject (C-k) to kill
> threads that are of no interest to me. However, when I am reading news the
> next day, I have to deal again with new messages from that thread. I'm
> wondering if I have a mechanism in Gnus to permanently hide a thread.
>
> In the manual, am seeing a lot of information about thread scoring, but
> I'm not sure if/how that is something I can leverage toward this end.
>
> --
> 📛 Christopher Howard
> 🚀 gemini://gem.librehacker.com
> 🌐 http://gem.librehacker.com
>
> בראשית ברא אלהים את השמים ואת הארץ
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> help-gnu-emacs mailing list
> help-gnu-emacs@gnu.org
> https://lists.gnu.org/mailman/listinfo/help-gnu-emacs
>
>
> ------------------------------
>
> End of help-gnu-emacs Digest, Vol 265, Issue 49
> ***********************************************
>


-- 
Marco Antoniotti
Somewhere over the Rainbow

Re: Retrieving the "include" directory for Emacs Modules

[Eli Zaretskii]

> From: Marco Antoniotti <marcoxa@gmail.com>
> Date: Fri, 13 Dec 2024 12:43:03 +0100
> 
> Hi Eli
> 
> What would be a proper place?

emacs-devel@gnu.org

Re: Retrieving the "include" directory for Emacs Modules

[Björn Bidar]

Stefan Monnier via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

>>> > As I tried to explain, if emacs-module.h is not installed in its
>>> > intended place, we cannot know where it is installed.
>>> The patch below would make sure that `emacs-module.h` is always
>>> available at `$(data-directory)/include/emacs-module.h`.
>> Sorry, this is wrong. [...] this is a change that will break previous
>> (and correct) behavior.
>
> I don't see how it would break anything: the .h file is still *also*
> copied to the $(includedir) for those people who want to compile their
> module outside of Emacs.
>
>> No compiler will look in that directory without a suitable -I option,
>
> That's OK: the sole purpose of the change is to let ELPA packages call
> `gcc` with such a `-I`!
>

Which is wrong for Unix-like systems except on macOS.

It's debatable if packages should compile their native modules
themselves but if they do they shouldn't change all systems just to
accommodate macOS and Windows.

Why not install the Emacs module header to PREFIX/include on these
platforms and deduct the path of the header similarly to how
eln-dest-dir is determined?

Re: Retrieving the "include" directory for Emacs Modules

[Eli Zaretskii]

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 20 Dec 2024 01:50:31 +0200
> 
> Why not install the Emacs module header to PREFIX/include on these
> platforms

We already do that.

> and deduct the path of the header similarly to how eln-dest-dir is
> determined?

This very complicated, due to the various ways people install Emacs,
the use of symlinks, and other similar issues.  We work very hard to
find the eln files; adding yet another similar (but different) code
path at startup is not my idea of fun.

And again, this list is the wrong place to discuss these issues.

Re: Retrieving the "include" directory for Emacs Modules

[Basile Starynkevitch]

On Fri, 2024-12-20 at 09:09 +0200, Eli Zaretskii wrote:
> > From: Björn Bidar <bjorn.bidar@thaodan.de>
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>
> > Date: Fri, 20 Dec 2024 01:50:31 +0200
> > 
> > Why not install the Emacs module header to PREFIX/include on these
> > platforms
> 
> We already do that.


A suggestion (perhaps a stupid one) might be to 

1. have some C function (or C #define) in PREFIX/include/emacs-module.h
give the installed PREFIX string. On my Linux Mint 22 (x86-64) desktop
the system file /usr/include/emacs-module.h is provided by package
emacs-common and apparently don't have any such thing  (I didn't look
inside the #include-d files). Of course I mean something better and
more robust than 

       #define EMACS_INCLUDE_FILE __FILE__


2. have an Elisp builtin function (maybe there is one already but C-h a
don't find it) which returns the Elisp string giving the prefix.

BTW I just git clone-d https://git.savannah.gnu.org/git/emacs.git into
my desktop's /usr/src/Editors/emacs directory 
(GNU emacs commit is 926a9c864adc29f056) and it fails to build after an
autogen.sh and a 
'./configure'  '--program-suffix=-trunk' '--with-x-toolkit=gtk3' \
   '--with-native-compilation' '--with-sqlite3' '--with-modules' \
   '--with-gpm' '--disable-silent-rules' '--without-rsvg' \
   'CFLAGS=-O2 -g' 'CC=/usr/bin/gcc-14'

the failure message is:
checking for gcc_jit_context_acquire in -lgccjit... yes
checking libgccjit.h usability... yes
checking libgccjit.h presence... yes
checking for libgccjit.h... yes
configure: error: The installed libgccjit failed to compile and run a
test program using
the libgccjit library; see config.log for the details of the failure.

But libgccjit is installed in 
/usr/lib/gcc/x86_64-linux-gnu/14/include/libgccjit.h

I also did compile gcc-15-20241215 from source code, so I also do have
a /usr/local/include/libgccjit.h file

My emacs config.log file can be downloaded by you before mid-january
2025 (at least on Linux) using
wget http://starynkevitch.net/Basile/emacs-926a9c864adc29f0-config.log
and its md5sum is 118c070dae8805c5c217a05b36659c18

At last my GPL licensed open source project is an inference engine on
https://github.com/RefPerSys/RefPerSys (coded in C++ and work in
progress). I eventually hope to make that RefPerSys (REFlexive
PERsistent SYStem) a GNU project and I even hope to have some students
(worldwide) contributing a bit to it.

Regards from near Paris in France.

NB. 15 years ago I contributed to GCC (plugin machinery).

-- 
Basile STARYNKEVITCH           <basile@starynkevitch.net>
8 rue de la Faïencerie
92340 Bourg-la-Reine,          France
http://starynkevitch.net/Basile & https://github.com/bstarynk 

Re: Retrieving the "include" directory for Emacs Modules

[Stefan Monnier]

>> That's OK: the sole purpose of the change is to let ELPA packages call
>> `gcc` with such a `-I`!
> Which is wrong for Unix-like systems except on macOS.

In which sense would it be wrong?
I can see an argument that such a `-I` would tend to be redundant on
systems where Emacs was "installed properly", but even on those systems
I fail to see what would be "wrong" about it.

> It's debatable if packages should compile their native modules
> themselves

IME it's what most users expect when they install (via `package.el`)
packages that come with a module, and it's also what most of the
developers of those packages want to offer to their users.
I have no intention to impose such an approach as the only supported way
to install a module, but I don't see what's debatable about providing
good support for packages to be able to compile their own modules.


        Stefan

Re: Retrieving the "include" directory for Emacs Modules

[Marco Antoniotti]

On Fri, Dec 20, 2024 at 6:02 PM <help-gnu-emacs-request@gnu.org> wrote:

>
> Message: 2
> Date: Fri, 20 Dec 2024 10:41:08 -0500
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> To: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: Stefan Monnier via Users list for the GNU Emacs text editor
>         <help-gnu-emacs@gnu.org>
> Subject: Re: Retrieving the "include" directory for Emacs Modules
> Message-ID: <jwvmsgqjrng.fsf-monnier+emacs@gnu.org>
> Content-Type: text/plain
>
> >> That's OK: the sole purpose of the change is to let ELPA packages call
> >> `gcc` with such a `-I`!
> > Which is wrong for Unix-like systems except on macOS.
>
> In which sense would it be wrong?
> I can see an argument that such a `-I` would tend to be redundant on
> systems where Emacs was "installed properly", but even on those systems
> I fail to see what would be "wrong" about it.
>

I obviously agree.  I would also contend that "Emacs installed properly"
should mean "installed according to the standards of the platform".

Now, on Windows this means (usually) "C:/Program Files/Emacs/emacs-MM.mm/",
with subdirs bin, include, lib. libexec and share.
This is not so far-off UN*X; it is "standard" (as per Microsoft) and yet it
is not what UN*X people, and, it appears, some Emacs people, would consider
"proper".

On Mac OS, https://emacsformacosx.com/ does a very good job of providing
batteries-included Emacs.  Its installation is, per Apple's ukazes, in
/Applicatiions/Emacs.app/Contents/Resources.  Note that this is a
"simplified" Apple installation, but surely it is "proper" under Mac OS.

Let me weigh in on another topic.  I teach and I have students come in
(second year CS) with all sorts of editors installed, Sublime, VSCode, Vim,
Eclipse, Notepad, whatever; no one uses Emacs.

First thing I do is to tell them to "install Emacs".

Do you (Björn) think that, apart from the very hard core
"I-already-know-Rust-and-C-sucks-because-I-recompiled-the-Linux-kernel-when-I-was-9-yo-on-my-Rasperry-pi"
three or four guys (they are obviously male) the majority is going to
"compile and install Emacs"?  They go to https://emacsformacosx.com/ and to
the https://www.gnu.org/software/emacs/download.html sites and download the
installers.  Or they use homebrew, snap or apt.

Bottom line, if you want our beloved editor to be used, lighten up.  (Yes,
I am patronizing; sorry; I am a boomer: TOWANDA :) ).

> It's debatable if packages should compile their native modules
> > themselves
>
> IME it's what most users expect when they install (via `package.el`)
> packages that come with a module, and it's also what most of the
> developers of those packages want to offer to their users.
> I have no intention to impose such an approach as the only supported way
> to install a module, but I don't see what's debatable about providing
> good support for packages to be able to compile their own modules.
>

Exactly.  Two thumbs up! TRT is to make the system as "open" as possible,
by playing ball with the platforms out there (at least Windows and Mac
OS).  People will find all sorts of ways to use the C compiler that they
have at hand; and no, these days the C compiler is not necessarily gcc, and
you should not assume it is.

That is why you need to expose the "Emacs configuration"; which means, at a
minimum, the 'include' directory for the header file(s) to build dynamic
Emacs modules.  Having a bunch of 'emacs-*' elisp variables/constants that
can be queried would be very helpful (hint: data-directory could be aliased
to emacs-data-directory).  I know this should move to the development list.

All the best

Marco

PS  Sorry Stefan, the "you" in the answer is not you personally; I believe
you are a French speaker, if you are, you know about 'tu' and 'vous' :)

-- 
Marco Antoniotti
Somewhere over the Rainbow

Re: Retrieving the "include" directory for Emacs Modules

[Arsen Arsenović]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Marco Antoniotti <marcoxa@gmail.com>
>> Date: Mon, 9 Dec 2024 10:58:57 +0100
>> 
>> On my Mac, If I install emacs as a "formula" (i.e., not a s an app) things
>> seem installed as they should be.  OTOH the brew "cask" (which installs a
>> .app in the Application directory) seems to create something that Apple
>> likes, but that STILL may be told to have a pointer to the include
>> directory as it does to the data-directory.
>> 
>> This is obviously something that the brew folks should deal with, but the
>> notion of having a variable that tracks the include directory still has
>> merit.  At least as an extra guideline to people like the brew maintainers.
>
> As I tried to explain, if emacs-module.h is not installed in its
> intended place, we cannot know where it is installed.  We only know
> that from the default installation locations we have in our Makefiles,
> but if some distros modify that, we cannot know.
>
> And I still contend that the correct installation should put this file
> where all the other header files are, and then the compiler will
> always find it.  Users who don't want to fight the uphill battle
> against brew could simply copy the file to the compiler's include
> directory, and be done.

Could I suggest installing a .pc file alongside Emacs that describes
this also?  That way, if distros modify it, they have a method of
notifying consumers of the modification also.

Have a lovely day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Retrieving the "include" directory for Emacs Modules

[Björn Bidar]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Fri, 20 Dec 2024 01:50:31 +0200
>> 
>> Why not install the Emacs module header to PREFIX/include on these
>> platforms
>
> We already do that.

So for example Emacs.app contains the module header in Emacs.app/include?

Re: Retrieving the "include" directory for Emacs Modules

[Björn Bidar]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> That's OK: the sole purpose of the change is to let ELPA packages call
>>> `gcc` with such a `-I`!
>> Which is wrong for Unix-like systems except on macOS.
>
> In which sense would it be wrong?
> I can see an argument that such a `-I` would tend to be redundant on
> systems where Emacs was "installed properly", but even on those systems
> I fail to see what would be "wrong" about it.

Headers don't go the Emacs data directory but in the include directory,
usually /usr/include or /usr/local/include.

>> It's debatable if packages should compile their native modules
>> themselves
>
> IME it's what most users expect when they install (via `package.el`)
> packages that come with a module, and it's also what most of the
> developers of those packages want to offer to their users.
> I have no intention to impose such an approach as the only supported way
> to install a module, but I don't see what's debatable about providing
> good support for packages to be able to compile their own modules.

I don't think about imposing anything but keeping in mind that modules
built arbitrary native code which can bring it's own issues especially
when external dependencies come into play.
Most packages which use native modules have to be adjusted to not built
the native module for themselves or from where to load the
native-module, some don't from load-path or no load-path for native
modules (they are not installed to datadir).

I wonder if there's something that could be learned from XEmacs approach
of emodules which were very similar. Especially the idea of ellcc[1] sounds
very good in this context.


-- 
[1] http://xemacs.org/Documentation/21.5/html/emodules_2.html#Using-ellcc

Re: Retrieving the "include" directory for Emacs Modules

[Björn Bidar]

Marco Antoniotti <marcoxa@gmail.com> writes:

> On Fri, Dec 20, 2024 at 6:02 PM <help-gnu-emacs-request@gnu.org> wrote:
>
>>
>> Message: 2
>> Date: Fri, 20 Dec 2024 10:41:08 -0500
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> To: Björn Bidar <bjorn.bidar@thaodan.de>
>> Cc: Stefan Monnier via Users list for the GNU Emacs text editor
>>         <help-gnu-emacs@gnu.org>
>> Subject: Re: Retrieving the "include" directory for Emacs Modules
>> Message-ID: <jwvmsgqjrng.fsf-monnier+emacs@gnu.org>
>> Content-Type: text/plain
>>
>> >> That's OK: the sole purpose of the change is to let ELPA packages call
>> >> `gcc` with such a `-I`!
>> > Which is wrong for Unix-like systems except on macOS.
>>
>> In which sense would it be wrong?
>> I can see an argument that such a `-I` would tend to be redundant on
>> systems where Emacs was "installed properly", but even on those systems
>> I fail to see what would be "wrong" about it.
>>
>
> I obviously agree.  I would also contend that "Emacs installed properly"
> should mean "installed according to the standards of the platform".


The proposal was add the module header to datadir not "installed
according to the standards of the platform".

> Now, on Windows this means (usually) "C:/Program Files/Emacs/emacs-MM.mm/",
> with subdirs bin, include, lib. libexec and share.
> This is not so far-off UN*X; it is "standard" (as per Microsoft) and yet it
> is not what UN*X people, and, it appears, some Emacs people, would consider
> "proper".

That's off-topic.

> On Mac OS, https://emacsformacosx.com/ does a very good job of providing
> batteries-included Emacs.  Its installation is, per Apple's ukazes, in
> /Applicatiions/Emacs.app/Contents/Resources.  Note that this is a
> "simplified" Apple installation, but surely it is "proper" under Mac OS.
>
> Let me weigh in on another topic.  I teach and I have students come in
> (second year CS) with all sorts of editors installed, Sublime, VSCode, Vim,
> Eclipse, Notepad, whatever; no one uses Emacs.
>
> First thing I do is to tell them to "install Emacs".
>
> Do you (Björn) think that, apart from the very hard core
> "I-already-know-Rust-and-C-sucks-because-I-recompiled-the-Linux-kernel-when-I-was-9-yo-on-my-Rasperry-pi"
> three or four guys (they are obviously male) the majority is going to
> "compile and install Emacs"?  They go to https://emacsformacosx.com/ and to
> the https://www.gnu.org/software/emacs/download.html sites and download the
> installers.  Or they use homebrew, snap or apt.


Such language is out of place here or anywhere else.. Especially
language which assumes gender stereotypes. 

> Bottom line, if you want our beloved editor to be used, lighten up.  (Yes,
> I am patronizing; sorry; I am a boomer: TOWANDA :) ).
>
>> It's debatable if packages should compile their native modules
>> > themselves
>>
>> IME it's what most users expect when they install (via `package.el`)
>> packages that come with a module, and it's also what most of the
>> developers of those packages want to offer to their users.
>> I have no intention to impose such an approach as the only supported way
>> to install a module, but I don't see what's debatable about providing
>> good support for packages to be able to compile their own modules.
>>
>
> Exactly.  Two thumbs up! TRT is to make the system as "open" as possible,
> by playing ball with the platforms out there (at least Windows and Mac
> OS).  People will find all sorts of ways to use the C compiler that they
> have at hand; and no, these days the C compiler is not necessarily gcc, and
> you should not assume it is.

Where GCC assumed somewhere besides writing GCC when CC was meant?
These days it has shifted from assuming CC is GCC that CC is Clang in
those projects that do mainly use Clang such as Chromium.
Emacs requires libgccjit for native compilation in this context is could
be very much assumed that CC is GCC. 

> That is why you need to expose the "Emacs configuration"; which means, at a
> minimum, the 'include' directory for the header file(s) to build dynamic
> Emacs modules.  Having a bunch of 'emacs-*' elisp variables/constants that
> can be queried would be very helpful (hint: data-directory could be aliased
> to emacs-data-directory).  I know this should move to the development list.

At least for the compiler configuration should not be needed as CC is
used on Unixi systems, on Windows that's an entirely different thing.
There's no need to define a variable for the include directory if the
include folder the header is in is installed into to the prefix directory of the Emacs
installation i.e. /usr on most Unixes, in the NextStep build Emacs.app
and on Windows 

In any case issues like could be resolved with something similar to
XEmacs's elcc.

Re: Retrieving the "include" directory for Emacs Modules

[Marco Antoniotti]

Hi,

after having looked into XEmacs elcc, i'd say that it may work.  Alas, that
would mean to distribute and maintain a different tool.

On Mon, Dec 23, 2024 at 9:15 PM Björn Bidar <bjorn.bidar@thaodan.de> wrote:

Marco Antoniotti <marcoxa@gmail.com> writes:
>
> > On Fri, Dec 20, 2024 at 6:02 PM <help-gnu-emacs-request@gnu.org> wrote:
> >
> >>
> >> Message: 2
> >> Date: Fri, 20 Dec 2024 10:41:08 -0500
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> To: Björn Bidar <bjorn.bidar@thaodan.de>
> >> Cc: Stefan Monnier via Users list for the GNU Emacs text editor
> >>         <help-gnu-emacs@gnu.org>
> >> Subject: Re: Retrieving the "include" directory for Emacs Modules
> >> Message-ID: <jwvmsgqjrng.fsf-monnier+emacs@gnu.org>
> >> Content-Type: text/plain
> >>
> >> >> That's OK: the sole purpose of the change is to let ELPA packages
> call
> >> >> `gcc` with such a `-I`!
> >> > Which is wrong for Unix-like systems except on macOS.
> >>
> >> In which sense would it be wrong?
> >> I can see an argument that such a `-I` would tend to be redundant on
> >> systems where Emacs was "installed properly", but even on those systems
> >> I fail to see what would be "wrong" about it.
> >>
> >
> > I obviously agree.  I would also contend that "Emacs installed properly"
> > should mean "installed according to the standards of the platform".
>
>
> The proposal was add the module header to datadir not "installed
> according to the standards of the platform".
>

Nope.  The proposal is to expose the Emacs installation 'include' directory
in such a way that it is possible to ask a batch emacs where it is so that
you can then use these values in your favorite build system.


>
> > Now, on Windows this means (usually) "C:/Program
> Files/Emacs/emacs-MM.mm/",
> > with subdirs bin, include, lib. libexec and share.
> > This is not so far-off UN*X; it is "standard" (as per Microsoft) and yet
> it
> > is not what UN*X people, and, it appears, some Emacs people, would
> consider
> > "proper".
>
> That's off-topic.
>

It surely does not seem so, given the previous discussion.


>
> > On Mac OS, https://emacsformacosx.com/ does a very good job of providing
> > batteries-included Emacs.  Its installation is, per Apple's ukazes, in
> > /Applicatiions/Emacs.app/Contents/Resources.  Note that this is a
> > "simplified" Apple installation, but surely it is "proper" under Mac OS.
> >
> > Let me weigh in on another topic.  I teach and I have students come in
> > (second year CS) with all sorts of editors installed, Sublime, VSCode,
> Vim,
> > Eclipse, Notepad, whatever; no one uses Emacs.
> >
> > First thing I do is to tell them to "install Emacs".
> >
> > Do you (Björn) think that, apart from the very hard core
> >
> "I-already-know-Rust-and-C-sucks-because-I-recompiled-the-Linux-kernel-when-I-was-9-yo-on-my-Rasperry-pi"
> > three or four guys (they are obviously male) the majority is going to
> > "compile and install Emacs"?  They go to https://emacsformacosx.com/
> and to
> > the https://www.gnu.org/software/emacs/download.html sites and download
> the
> > installers.  Or they use homebrew, snap or apt.
>
>
> Such language is out of place here or anywhere else.. Especially
> language which assumes gender stereotypes.
>

Sorry.  I tend to observe and use humor.  If you have other data points
with proper statistics (number of women who think that C sucks because they
like Rust), I will update the jokes.


> > Bottom line, if you want our beloved editor to be used, lighten up.
> (Yes,
> > I am patronizing; sorry; I am a boomer: TOWANDA :) ).
> >
> >> It's debatable if packages should compile their native modules
> >> > themselves
> >>
> >> IME it's what most users expect when they install (via `package.el`)
> >> packages that come with a module, and it's also what most of the
> >> developers of those packages want to offer to their users.
> >> I have no intention to impose such an approach as the only supported way
> >> to install a module, but I don't see what's debatable about providing
> >> good support for packages to be able to compile their own modules.
> >>
> >
> > Exactly.  Two thumbs up! TRT is to make the system as "open" as possible,
> > by playing ball with the platforms out there (at least Windows and Mac
> > OS).  People will find all sorts of ways to use the C compiler that they
> > have at hand; and no, these days the C compiler is not necessarily gcc,
> and
> > you should not assume it is.
>
> Where GCC assumed somewhere besides writing GCC when CC was meant?
> These days it has shifted from assuming CC is GCC that CC is Clang in
> those projects that do mainly use Clang such as Chromium.
> Emacs requires libgccjit for native compilation in this context is could
> be very much assumed that CC is GCC.
>

I just tested my emacs module compiling with the MSVS toolchain.  Works
like a charm, just like the clang setup on Mac OS; but I must hard code the
Emacs 'include' directory, which I just happen to know where it is.


>
> > That is why you need to expose the "Emacs configuration"; which means,
> at a
> > minimum, the 'include' directory for the header file(s) to build dynamic
> > Emacs modules.  Having a bunch of 'emacs-*' elisp variables/constants
> that
> > can be queried would be very helpful (hint: data-directory could be
> aliased
> > to emacs-data-directory).  I know this should move to the development
> list.
>
> At least for the compiler configuration should not be needed as CC is
> used on Unixi systems, on Windows that's an entirely different thing.
> There's no need to define a variable for the include directory if the
> include folder the header is in is installed into to the prefix directory
> of the Emacs
> installation i.e. /usr on most Unixes, in the NextStep build Emacs.app
> and on Windows
>

That's exactly why we need to expose the location of the 'include', plus I
believe the maintainer of https://emacsformacos.com/ has a different
opinion.
The whole point is that Emacs must be usable everywhere and that its use
must be made as easy as possible, for the case at hand, module writers.

Your argument is just "we must stick to unixi setups"; the counterargument
is that exposing constants that tell a user how Emacs is installed on a
given platform is not that big of a deal and gives leverage and freedom to
emacs module writers, and probably to package writers as well.


>
> In any case issues like could be resolved with something similar to
> XEmacs's elcc.
>

Maybe.  Maybe not.

Happy Holidays


-- 
Marco Antoniotti
Somewhere over the Rainbow

Re: Retrieving the "include" directory for Emacs Modules

[Stefan Monnier]

>>>> That's OK: the sole purpose of the change is to let ELPA packages call
>>>> `gcc` with such a `-I`!
>>> Which is wrong for Unix-like systems except on macOS.
>> In which sense would it be wrong?
>> I can see an argument that such a `-I` would tend to be redundant on
>> systems where Emacs was "installed properly", but even on those systems
>> I fail to see what would be "wrong" about it.
> Headers don't go the Emacs data directory but in the include directory,
> usually /usr/include or /usr/local/include.

"Unusual" doesn't mean "wrong".  So, I don't think it's a valid
description of something that would be "wrong" about it.

[ BTW, `locate '*.h' | sed 's|[^/]*$||' | sort -u` on this Debian system
  suggests Emacs would be far from the only package to place header files
  outside of `/usr/include` or `/usr/local/include`.  ]

> I don't think about imposing anything but keeping in mind that modules
> built arbitrary native code which can bring it's own issues especially
> when external dependencies come into play.

Indeed, beside finding Emacs's own header file, there can be various
other hurdles to making a module that can be built on "all" systems.

> I wonder if there's something that could be learned from XEmacs approach
> of emodules which were very similar.

I'd be surprised if there isn't something to learn from them, indeed.

> Especially the idea of ellcc[1] sounds very good in this context.

AFAICT this deals with the issue of how to build a "shared lib" kind of
object file, IOW something that solves the same kinds of problem that
Libtool aims to solve, right?

Maybe we should develop a "module-helper" package which provides various
helpers to build modules.


        Stefan

Re: Retrieving the "include" directory for Emacs Modules

[Stefan Monnier via Users list for the GNU Emacs text editor]

> after having looked into XEmacs elcc, i'd say that it may work.  Alas, that
> would mean to distribute and maintain a different tool.

Your ELPA package will need to find that `elcc` tool and that `elcc`
tool will in turn need to find the header file.

If Emacs was installed in a "Portable" style (e.g. a tarball untar'd at
some arbitrary location), then those two steps will face the exact same
problem we're discussing.


        Stefan

Re: Retrieving the "include" directory for Emacs Modules

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Stefan Monnier via Users list for the GNU Emacs text editor
>  <help-gnu-emacs@gnu.org>
> Date: Tue, 24 Dec 2024 00:06:07 -0500
> 
> [ BTW, `locate '*.h' | sed 's|[^/]*$||' | sort -u` on this Debian system
>   suggests Emacs would be far from the only package to place header files
>   outside of `/usr/include` or `/usr/local/include`.  ]

Careful: the above might pick up header files private to source
distributions if you have them on your system (i.e., if you build
packages locally from sources).  By contrast, this discussion is about
_public_ header files, ones installed with the purpose of letting
other packages interface with the package whose header file is
installed.

Re: Retrieving the "include" directory for Emacs Modules

[Stefan Monnier via Users list for the GNU Emacs text editor]

> Careful: the above might pick up header files private to source
> distributions if you have them on your system (i.e., if you build
> packages locally from sources).  By contrast, this discussion is about
> _public_ header files, ones installed with the purpose of letting
> other packages interface with the package whose header file is
> installed.

I'll let you judge.


        Stefan


% locate '*.h' | sed 's|[^/]*$||' | sort -u | grep -v 'monnier\|/usr/include'
/usr/lib/clisp-2.49.93+/base/
/usr/lib/clisp-2.49.93+/linkkit/
/usr/lib/gcc/x86_64-linux-gnu/10/include/
/usr/lib/gcc/x86_64-linux-gnu/10/include/sanitizer/
/usr/lib/gcc/x86_64-linux-gnu/12/include/
/usr/lib/gcc/x86_64-linux-gnu/12/include/sanitizer/
/usr/lib/ghc/
/usr/lib/ghc/base-4.15.1.0/include/
/usr/lib/ghc/bytestring-0.10.12.1/include/
/usr/lib/ghc/ghc-9.0.2/include/
/usr/lib/ghc/ghc-bignum-1.1/include/
/usr/lib/ghc/include/
/usr/lib/ghc/include/rts/
/usr/lib/ghc/include/rts/prof/
/usr/lib/ghc/include/rts/storage/
/usr/lib/ghc/include/stg/
/usr/lib/ghc/process-1.6.13.2/include/
/usr/lib/ghc/time-1.9.3/include/
/usr/lib/ghc/unix-2.7.2.2/include/
/usr/lib/gprolog/include/
/usr/lib/grub/i386-pc/
/usr/lib/grub/x86_64-efi/
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-9.0.2/primitive-0.7.3.0-EikPDi9CXNiB9f5MDJybeY/include/
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-9.0.2/vector-0.12.3.1-TXkE6leK98EdYcmdk29JF/include/
/usr/lib/jvm/java-17-openjdk-amd64/include/
/usr/lib/jvm/java-17-openjdk-amd64/include/linux/
/usr/lib/llvm-14/lib/clang/14.0.6/include/
/usr/lib/llvm-14/lib/clang/14.0.6/include/openmp_wrappers/
/usr/lib/llvm-14/lib/clang/14.0.6/include/ppc_wrappers/
/usr/lib/llvm-14/lib/clang/14.0.6/include/xray/
/usr/lib/ocaml/caml/
/usr/lib/ocaml/zarith/
/usr/lib/python3/dist-packages/dulwich/
/usr/lib/python3/dist-packages/greenlet/
/usr/lib/python3/dist-packages/greenlet/platform/
/usr/lib/python3/dist-packages/lxml/
/usr/lib/python3/dist-packages/lxml/includes/
/usr/lib/swi-prolog/include/
/usr/lib/swi-prolog/include/sicstus/
/usr/lib/swi-prolog/include/Yap/
/usr/lib/x86_64-linux-gnu/dbus-1.0/include/dbus/
/usr/lib/x86_64-linux-gnu/glib-2.0/include/
/usr/lib/x86_64-linux-gnu/perl/5.36.0/CORE/
/usr/lib/x86_64-linux-gnu/perl5/5.36/B/Hooks/OP/Check/Install/
/usr/lib/x86_64-linux-gnu/perl5/5.36/Cairo/Install/
/usr/lib/x86_64-linux-gnu/perl5/5.36/Encode/
/usr/lib/x86_64-linux-gnu/perl5/5.36/Glib/Install/
/usr/lib/xemacs-21.4.24/x86_64-linux-gnu/include/
/usr/lib/xemacs-21.4.24/x86_64-linux-gnu/include/m/
/usr/lib/xemacs-21.4.24/x86_64-linux-gnu/include/s/
/usr/share/cmake-3.25/include/
/usr/share/cmake-3.25/Modules/
/usr/share/cups/ppdc/
/usr/share/doc/bison/examples/c/mfcalc/
/usr/share/doc/guile-3.0-dev/examples/compat/
/usr/share/doc/libzstd-dev/examples/
/usr/share/doc/nettle-dev/examples/
/usr/share/doc/printer-driver-pnm2ppa/pl/
/usr/share/doc/zlib1g-dev/examples/
/usr/share/gettext/
/usr/share/go-1.19/misc/cgo/life/testdata/
/usr/share/go-1.19/misc/cgo/test/
/usr/share/go-1.19/misc/cgo/testplugin/testdata/issue25756/plugin/
/usr/share/go-1.19/misc/cgo/testsovar/testdata/
/usr/share/go-1.19/misc/cgo/test/testdata/gcc68255/
/usr/share/go-1.19/misc/cgo/test/testdata/issue20266/
/usr/share/go-1.19/misc/cgo/test/testdata/issue26213/
/usr/share/go-1.19/misc/cgo/test/testdata/issue27054/
/usr/share/go-1.19/misc/swig/callback/
/usr/share/go-1.19/pkg/include/
/usr/share/go-1.19/src/crypto/internal/boring/
/usr/share/go-1.19/src/debug/dwarf/testdata/
/usr/share/go-1.19/src/debug/gosym/testdata/
/usr/share/go-1.19/src/runtime/
/usr/share/go-1.19/src/runtime/cgo/
/usr/share/grub/
/usr/share/libtool/
/usr/share/libtool/libltdl/
/usr/share/perl/5.36.0/Encode/
/usr/share/smartmontools/
/usr/src/libdvd-pkg/build/
/usr/src/libdvd-pkg/build/msvc/
/usr/src/libdvd-pkg/build/src/
/usr/src/libdvd-pkg/build/src/dvdcss/
/usr/src/linux-apfs-rw-0.3.0-1/
/usr/src/linux-apfs-rw-0.3.0-1/lzfse/
/var/lib/smartmontools/drivedb/
% 

Re: Retrieving the "include" directory for Emacs Modules

[Eli Zaretskii]

> Date: Tue, 24 Dec 2024 10:30:41 -0500
> From:  Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> > Careful: the above might pick up header files private to source
> > distributions if you have them on your system (i.e., if you build
> > packages locally from sources).  By contrast, this discussion is about
> > _public_ header files, ones installed with the purpose of letting
> > other packages interface with the package whose header file is
> > installed.
> 
> I'll let you judge.
> 
> 
>         Stefan
> 
> 
> % locate '*.h' | sed 's|[^/]*$||' | sort -u | grep -v 'monnier\|/usr/include'
> /usr/lib/clisp-2.49.93+/base/
> /usr/lib/clisp-2.49.93+/linkkit/
> /usr/lib/gcc/x86_64-linux-gnu/10/include/
> /usr/lib/gcc/x86_64-linux-gnu/10/include/sanitizer/
> /usr/lib/gcc/x86_64-linux-gnu/12/include/
> /usr/lib/gcc/x86_64-linux-gnu/12/include/sanitizer/
> /usr/lib/ghc/
> /usr/lib/ghc/base-4.15.1.0/include/
> /usr/lib/ghc/bytestring-0.10.12.1/include/
> /usr/lib/ghc/ghc-9.0.2/include/
> /usr/lib/ghc/ghc-bignum-1.1/include/
> /usr/lib/ghc/include/
> /usr/lib/ghc/include/rts/
> /usr/lib/ghc/include/rts/prof/
> /usr/lib/ghc/include/rts/storage/
> /usr/lib/ghc/include/stg/
> /usr/lib/ghc/process-1.6.13.2/include/
> /usr/lib/ghc/time-1.9.3/include/
> /usr/lib/ghc/unix-2.7.2.2/include/
> /usr/lib/gprolog/include/
> /usr/lib/grub/i386-pc/
> /usr/lib/grub/x86_64-efi/
> /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-9.0.2/primitive-0.7.3.0-EikPDi9CXNiB9f5MDJybeY/include/
> /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-9.0.2/vector-0.12.3.1-TXkE6leK98EdYcmdk29JF/include/
> /usr/lib/jvm/java-17-openjdk-amd64/include/
> /usr/lib/jvm/java-17-openjdk-amd64/include/linux/
> /usr/lib/llvm-14/lib/clang/14.0.6/include/
> /usr/lib/llvm-14/lib/clang/14.0.6/include/openmp_wrappers/
> /usr/lib/llvm-14/lib/clang/14.0.6/include/ppc_wrappers/
> /usr/lib/llvm-14/lib/clang/14.0.6/include/xray/
> /usr/lib/ocaml/caml/
> /usr/lib/ocaml/zarith/
> /usr/lib/python3/dist-packages/dulwich/
> /usr/lib/python3/dist-packages/greenlet/
> /usr/lib/python3/dist-packages/greenlet/platform/
> /usr/lib/python3/dist-packages/lxml/
> /usr/lib/python3/dist-packages/lxml/includes/
> /usr/lib/swi-prolog/include/
> /usr/lib/swi-prolog/include/sicstus/
> /usr/lib/swi-prolog/include/Yap/
> /usr/lib/x86_64-linux-gnu/dbus-1.0/include/dbus/
> /usr/lib/x86_64-linux-gnu/glib-2.0/include/
> /usr/lib/x86_64-linux-gnu/perl/5.36.0/CORE/
> /usr/lib/x86_64-linux-gnu/perl5/5.36/B/Hooks/OP/Check/Install/
> /usr/lib/x86_64-linux-gnu/perl5/5.36/Cairo/Install/
> /usr/lib/x86_64-linux-gnu/perl5/5.36/Encode/
> /usr/lib/x86_64-linux-gnu/perl5/5.36/Glib/Install/
> /usr/lib/xemacs-21.4.24/x86_64-linux-gnu/include/
> /usr/lib/xemacs-21.4.24/x86_64-linux-gnu/include/m/
> /usr/lib/xemacs-21.4.24/x86_64-linux-gnu/include/s/
> /usr/share/cmake-3.25/include/
> /usr/share/cmake-3.25/Modules/
> /usr/share/cups/ppdc/
> /usr/share/doc/bison/examples/c/mfcalc/
> /usr/share/doc/guile-3.0-dev/examples/compat/
> /usr/share/doc/libzstd-dev/examples/
> /usr/share/doc/nettle-dev/examples/
> /usr/share/doc/printer-driver-pnm2ppa/pl/
> /usr/share/doc/zlib1g-dev/examples/
> /usr/share/gettext/
> /usr/share/go-1.19/misc/cgo/life/testdata/
> /usr/share/go-1.19/misc/cgo/test/
> /usr/share/go-1.19/misc/cgo/testplugin/testdata/issue25756/plugin/
> /usr/share/go-1.19/misc/cgo/testsovar/testdata/
> /usr/share/go-1.19/misc/cgo/test/testdata/gcc68255/
> /usr/share/go-1.19/misc/cgo/test/testdata/issue20266/
> /usr/share/go-1.19/misc/cgo/test/testdata/issue26213/
> /usr/share/go-1.19/misc/cgo/test/testdata/issue27054/
> /usr/share/go-1.19/misc/swig/callback/
> /usr/share/go-1.19/pkg/include/
> /usr/share/go-1.19/src/crypto/internal/boring/
> /usr/share/go-1.19/src/debug/dwarf/testdata/
> /usr/share/go-1.19/src/debug/gosym/testdata/
> /usr/share/go-1.19/src/runtime/
> /usr/share/go-1.19/src/runtime/cgo/
> /usr/share/grub/
> /usr/share/libtool/
> /usr/share/libtool/libltdl/
> /usr/share/perl/5.36.0/Encode/
> /usr/share/smartmontools/
> /usr/src/libdvd-pkg/build/
> /usr/src/libdvd-pkg/build/msvc/
> /usr/src/libdvd-pkg/build/src/
> /usr/src/libdvd-pkg/build/src/dvdcss/
> /usr/src/linux-apfs-rw-0.3.0-1/
> /usr/src/linux-apfs-rw-0.3.0-1/lzfse/
> /var/lib/smartmontools/drivedb/
> % 

Those under /usr/lib are looked in by the relevant compilers (they are
include directories private to those compilers, hard-coded into them
when they are built).  Those under /usr/share are private to the
relevant packages, and are either examples or test suites (thus AFAIU
unrelated to the issue at hand here).  Those under /usr/src are what I
mentioned: private headers needed to build a package.

Re: Retrieving the "include" directory for Emacs Modules

[Björn Bidar]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 24 Dec 2024 10:30:41 -0500
>> From:  Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
>> 
>> > Careful: the above might pick up header files private to source
>> > distributions if you have them on your system (i.e., if you build
>> > packages locally from sources).  By contrast, this discussion is about
>> > _public_ header files, ones installed with the purpose of letting
>> > other packages interface with the package whose header file is
>> > installed.
>> 
>> I'll let you judge.
>> 
>> 
>>         Stefan
>> 
>> 
>> % locate '*.h' | sed 's|[^/]*$||' | sort -u | grep -v 'monnier\|/usr/include'
>> /usr/lib/clisp-2.49.93+/base/
>> /usr/lib/clisp-2.49.93+/linkkit/
>> /usr/lib/gcc/x86_64-linux-gnu/10/include/
>> /usr/lib/gcc/x86_64-linux-gnu/10/include/sanitizer/
>> /usr/lib/gcc/x86_64-linux-gnu/12/include/
>> /usr/lib/gcc/x86_64-linux-gnu/12/include/sanitizer/
>> /usr/lib/ghc/
>> /usr/lib/ghc/base-4.15.1.0/include/
>> /usr/lib/ghc/bytestring-0.10.12.1/include/
>> /usr/lib/ghc/ghc-9.0.2/include/
>> /usr/lib/ghc/ghc-bignum-1.1/include/
>> /usr/lib/ghc/include/
>> /usr/lib/ghc/include/rts/
>> /usr/lib/ghc/include/rts/prof/
>> /usr/lib/ghc/include/rts/storage/
>> /usr/lib/ghc/include/stg/
>> /usr/lib/ghc/process-1.6.13.2/include/
>> /usr/lib/ghc/time-1.9.3/include/
>> /usr/lib/ghc/unix-2.7.2.2/include/
>> /usr/lib/gprolog/include/
>> /usr/lib/grub/i386-pc/
>> /usr/lib/grub/x86_64-efi/
>> /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-9.0.2/primitive-0.7.3.0-EikPDi9CXNiB9f5MDJybeY/include/
>> /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-9.0.2/vector-0.12.3.1-TXkE6leK98EdYcmdk29JF/include/
>> /usr/lib/jvm/java-17-openjdk-amd64/include/
>> /usr/lib/jvm/java-17-openjdk-amd64/include/linux/
>> /usr/lib/llvm-14/lib/clang/14.0.6/include/
>> /usr/lib/llvm-14/lib/clang/14.0.6/include/openmp_wrappers/
>> /usr/lib/llvm-14/lib/clang/14.0.6/include/ppc_wrappers/
>> /usr/lib/llvm-14/lib/clang/14.0.6/include/xray/
>> /usr/lib/ocaml/caml/
>> /usr/lib/ocaml/zarith/
>> /usr/lib/python3/dist-packages/dulwich/
>> /usr/lib/python3/dist-packages/greenlet/
>> /usr/lib/python3/dist-packages/greenlet/platform/
>> /usr/lib/python3/dist-packages/lxml/
>> /usr/lib/python3/dist-packages/lxml/includes/
>> /usr/lib/swi-prolog/include/
>> /usr/lib/swi-prolog/include/sicstus/
>> /usr/lib/swi-prolog/include/Yap/
>> /usr/lib/x86_64-linux-gnu/dbus-1.0/include/dbus/
>> /usr/lib/x86_64-linux-gnu/glib-2.0/include/
>> /usr/lib/x86_64-linux-gnu/perl/5.36.0/CORE/
>> /usr/lib/x86_64-linux-gnu/perl5/5.36/B/Hooks/OP/Check/Install/
>> /usr/lib/x86_64-linux-gnu/perl5/5.36/Cairo/Install/
>> /usr/lib/x86_64-linux-gnu/perl5/5.36/Encode/
>> /usr/lib/x86_64-linux-gnu/perl5/5.36/Glib/Install/
>> /usr/lib/xemacs-21.4.24/x86_64-linux-gnu/include/
>> /usr/lib/xemacs-21.4.24/x86_64-linux-gnu/include/m/
>> /usr/lib/xemacs-21.4.24/x86_64-linux-gnu/include/s/
>> /usr/share/cmake-3.25/include/
>> /usr/share/cmake-3.25/Modules/

Those are cmake test headers.

>> /usr/share/cups/ppdc/
>> /usr/share/doc/bison/examples/c/mfcalc/
>> /usr/share/doc/guile-3.0-dev/examples/compat/
>> /usr/share/doc/libzstd-dev/examples/
>> /usr/share/doc/nettle-dev/examples/
>> /usr/share/doc/printer-driver-pnm2ppa/pl/
>> /usr/share/doc/zlib1g-dev/examples/
>> /usr/share/gettext/
>> /usr/share/go-1.19/misc/cgo/life/testdata/
>> /usr/share/go-1.19/misc/cgo/test/
>> /usr/share/go-1.19/misc/cgo/testplugin/testdata/issue25756/plugin/
>> /usr/share/go-1.19/misc/cgo/testsovar/testdata/
>> /usr/share/go-1.19/misc/cgo/test/testdata/gcc68255/
>> /usr/share/go-1.19/misc/cgo/test/testdata/issue20266/
>> /usr/share/go-1.19/misc/cgo/test/testdata/issue26213/
>> /usr/share/go-1.19/misc/cgo/test/testdata/issue27054/
>> /usr/share/go-1.19/misc/swig/callback/
>> /usr/share/go-1.19/pkg/include/
>> /usr/share/go-1.19/src/crypto/internal/boring/
>> /usr/share/go-1.19/src/debug/dwarf/testdata/
>> /usr/share/go-1.19/src/debug/gosym/testdata/
>> /usr/share/go-1.19/src/runtime/
>> /usr/share/go-1.19/src/runtime/cgo/
>> /usr/share/grub/
>> /usr/share/libtool/
>> /usr/share/libtool/libltdl/
>> /usr/share/perl/5.36.0/Encode/
>> /usr/share/smartmontools/
>> /usr/src/libdvd-pkg/build/
>> /usr/src/libdvd-pkg/build/msvc/
>> /usr/src/libdvd-pkg/build/src/
>> /usr/src/libdvd-pkg/build/src/dvdcss/
>> /usr/src/linux-apfs-rw-0.3.0-1/
>> /usr/src/linux-apfs-rw-0.3.0-1/lzfse/
>> /var/lib/smartmontools/drivedb/
>> % 
>
> Those under /usr/lib are looked in by the relevant compilers (they are
> include directories private to those compilers, hard-coded into them
> when they are built).  Those under /usr/share are private to the
> relevant packages, and are either examples or test suites (thus AFAIU
> unrelated to the issue at hand here).  Those under /usr/src are what I
> mentioned: private headers needed to build a package.

In addition some of them could be overlooked by distribution packagers