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