Re: Retrieving the "include" directory for Emacs Modules

["Björn Bidar" <bjorn.bidar@thaodan.de>]

Marco Antoniotti <marcoxa@gmail.com> writes:

> 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.

Do you have Emacs.app or not? The normal way does not use Emacs.app.

>> >>
>> >> > 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".

My point is if you use flatpak you should pull your dependencies from
Flatpak or you break the main purpose for using the Flatpak sandbox
completely, at that point you can also install Emacs without Flatpak and
have the same results with less issues.

>> 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?
>

What does this have to do with VS Code? What is exposing
Include-directory?
If I understand correctly there should be include folder in the Windows
build and inside Emacs.app folder. Adding the include directory relative
to the prefix of the Emacs installation might be a ok workaround for
these platforms.

For the others where the compiler searches for the headers in the
default path where it was installed by the package manager it would
explicitly add the default include path to the list of folders to search
which might not be the users intention, i.e. it could have side effects.

I does not make sense to apply platform specific workarounds to all 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?

Python? Context?