Re: Retrieving the "include" directory for Emacs Modules

[Stefan Monnier]

>> Compile manually and run from the build tree?
> That's called "run uninstalled".  And in that case, the user who does
> that knows very well where the header lives: in the same directory
> from which he/she runs Emacs.

Why would they know that?  I mean, of course, some will, but many people
compile their own Emacs just to live on the bleeding edge and may never
really look at the C code.

[ Personally, I knew that *an* `emacs-module.h` file lived in there, but
  I wasn't 100% sure it's the right one to use (I expected there might
  be another one in some other directory).  ]

>> Uncompress a downloaded pre-compiled archive into a directory and just
>> use it from there (AFAIK, very common under macOS and Windows)?
> If that doesn't place emacs-module.h in the system-wide include
> directory, it is a broken installation.

If the user doesn't have administrator rights, then the installation
can't really be blamed for not adding itself to a system-wide
include directory.

>> Emacs *should* know that, just like it knows where is its
>> `lisp-directory`.
> That's impractical expectation.

We decide where the .h file is put, so it's really not.

> Recall how hard we worked to find the pdumper file and the preloaded
> *.eln files, what with all the tricks people use when
> installing Emacs.

Yup.  And we don't need anything *more*.  We just need to place the
include file at a place that's easy to find once we know the rest.
E.g. it could be `$(data-directory)/module-include`.

> I'm not interested in adding another burden to our maintenance so that
> Emacs will paper over broken installations.

The system-wide install may have an older version of Emacs than the one
from which we want to compile a module.

It's good that we expose `emacs-module.h` system-wide, but I think it's
even more important for Emacs to be able to compile its own modules
without having to rely on that.


        Stefan