Re: Dynamic loading progress

[Eli Zaretskii]

> From: Stephen Leake <address@hidden>
> Date: Sun, 15 Feb 2015 13:09:25 -0600
> 
> > That "metainfo", whatever it will be, will also have to support
> > compilation of modules: we need to know at compile time what values of
> > USE_LSB_TAG, ENABLE_CHECKING, WIDE_EMACS_INT, optimization flags,
> > etc. were used when Emacs was built, because those affect the layout
> > of objects inside Emacs and also the availability of certain functions
> > in the Emacs binary.
> 
> Right.
> 
> One solution is to only distribute source, and provide an elisp function
> 'module-make' (suggested by Stefan) that provides command-line options
> to a module makefile for all of those settings.

That's a beginning, but it cannot be all there is to, because modules
should be distributable in binary form as well, at least some Linux
distributions will probably want that.

> So let's take a stab at something closer to your approach.
> 
> I'm not familiar with the idioms for making an opaque type in C; would
> that just be a pointer to void? something like:
> 
> typedef void*  Lisp_Object_Ptr;

I'd go with

  typedef intmax_t Lisp_Object;

This should be wide enough to hold both a pointer and the widest
integer type, although I think its being wide enough for a pointer is
not guaranteed by the C standard.

Another suggestion, from Stefan, was to use EMACS_INT, but I'm not
sure we will be able to define it correctly without dragging in too
much stuff from lisp.h that is used there to define EMACS_INT.  Maybe
we should have a separate definition of EMACS_INT for modules.