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.