Re: Retrieving the "include" directory for Emacs Modules

[Marco Antoniotti <marcoxa@gmail.com>]

On Fri, Jan 3, 2025 at 1:12 AM Björn Bidar <bjorn.bidar@thaodan.de> wrote:

> Marco Antoniotti <marcoxa@gmail.com> writes:
>
> > Hello and Happy New (Hacking) Year.
> >
> > apologies if I insist on this issue.
> >
> > On Sun, Dec 29, 2024 at 6:53 PM <help-gnu-emacs-request@gnu.org> wrote:
> >
> >> Message: 5
> >> Date: Sun, 29 Dec 2024 03:03:53 +0200
> >> From: Björn Bidar <bjorn.bidar@thaodan.de>
> >> To: Stefan Monnier via Users list for the GNU Emacs text editor
> >>         <help-gnu-emacs@gnu.org>
> >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Subject: Re: Retrieving the "include" directory for Emacs Modules
> >> Message-ID: <8734i7i9l2.fsf@>
> >> Content-Type: text/plain
> >>
> >> Stefan Monnier via Users list for the GNU Emacs text editor
> >> <help-gnu-emacs@gnu.org> writes:
> >>
> >> >> 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.
> >> >
> >> > Indeed, they each have their own reason to exist.  And this is in
> Debian,
> >> > i.e. a distribution which is very careful to install things in the one
> >> > central place where they belong.
> >>
> >> I'm on openSUSE which is entirely unrelated same policy. In fact all
> >> Unixes have such a policy (macOS doesn't count in this context).
> >>
> >
> > ... and why exactly MacOSX (and Windows) "don't count in this context"?
> > And what is the "context"?
>
> I wrote macOS (the is no longer in the name) does not count in the
> sentence as Unix as the NextStep/GNUStep build of Emacs uses an app
> bundle which does not install into a prefix directory normally.
>
>
It installs "normally" as far as Mac OS (X or not) is concerned.


> >>
> >> > Other relevant cases will look very different:
> >> > Emacs.app, AppImages, Snap packages, etc...
> >>
> >> Who are proprietary platforms such as Snap relevant to Emacs? For these
> >> where a sandbox is involved such as Snap or Flatpak it is not possible
> >> to interact with external resources without breaking the security of the
> >> sandbox.
> >>
> >
> >> But anyway this is going off-topic.
> >>
> >>
> > How exaclty does having
> >
> > include-directory
> >
> > (and the other variables) available, break the sandbox?  Or anything
> else?
>
> If Emacs is installed from Flatpak loading libraries outside of that
> sandbox break the security of it. Building modules inherently requires
> to call external binaries to link against external dependencies.
>

Oh come on!  Emacs is not exactly the "safest" of environments.  Your
argument here boils down to "do not build Emacs Modules".

> The issue here is accommodating the wider world.
>
> It is but accommodating the wider world ultimately only mattered for
> free open source platforms not on the non-free platforms supported by
> Emacs.
> I don't say that is what should happen here but the workarounds required
> for some platforms should not affect others.
>

And how exposing 'include-directory' would affect you?  Or VS Code (which,
I remind you, is what the vast majority of incoming students uses)?  Or
FOSS platforms?


> > Personal historical note.  I first used Emacs on a Zentih z8000.  The
> first
> > GNU Emacs I used was on a Sun 3/60.  I also used it on AIX and, if memory
> > does not fail me, on a microVAX with VMS (this I may be wrong).
> >
> > These were (are) all proprietary platforms.  "Unixy" but proprietary.  As
> > MacOSX.
> >
> > Do you want people to use Emacs?  Let them have access to it without
> > imposing needless constraints.
> >
>
> The issue is something which was known before the module system was
> added to Emacs, that requiring to compile native code for interfacing
> with other libraries complicates things. Which is why XEmacs had helper
> programs or function to automate much of this process.
>
> Native modules have their place but it was criticized that comparing to
> native
> modules FFI would have been simpler as no native code would have had to
> be compiled just to interface with external libraries.
>

... great.  Now, let me ask you: why are we inflicted (I feel
"inflicted" 😑 ) Python (a FOSS language) instead of writing lovely
parentheses?

All the best

MA



-- 
Marco Antoniotti
Somewhere over the Rainbow