Re: Retrieving the "include" directory for Emacs Modules

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

Headers don't go the Emacs data directory but in the include directory,
usually /usr/include or /usr/local/include.

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

I don't think about imposing anything but keeping in mind that modules
built arbitrary native code which can bring it's own issues especially
when external dependencies come into play.
Most packages which use native modules have to be adjusted to not built
the native module for themselves or from where to load the
native-module, some don't from load-path or no load-path for native
modules (they are not installed to datadir).

I wonder if there's something that could be learned from XEmacs approach
of emodules which were very similar. Especially the idea of ellcc[1] sounds
very good in this context.


-- 
[1] http://xemacs.org/Documentation/21.5/html/emodules_2.html#Using-ellcc