Re: Retrieving the "include" directory for Emacs Modules

[Stefan Monnier]

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

"Unusual" doesn't mean "wrong".  So, I don't think it's a valid
description of something that would be "wrong" about it.

[ BTW, `locate '*.h' | sed 's|[^/]*$||' | sort -u` on this Debian system
  suggests Emacs would be far from the only package to place header files
  outside of `/usr/include` or `/usr/local/include`.  ]

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

Indeed, beside finding Emacs's own header file, there can be various
other hurdles to making a module that can be built on "all" systems.

> I wonder if there's something that could be learned from XEmacs approach
> of emodules which were very similar.

I'd be surprised if there isn't something to learn from them, indeed.

> Especially the idea of ellcc[1] sounds very good in this context.

AFAICT this deals with the issue of how to build a "shared lib" kind of
object file, IOW something that solves the same kinds of problem that
Libtool aims to solve, right?

Maybe we should develop a "module-helper" package which provides various
helpers to build modules.


        Stefan