Re: Retrieving the "include" directory for Emacs Modules

[Marco Antoniotti <marcoxa@gmail.com>]

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