Re: Dynamic loading progress

[Stefan Monnier]

> Ok. I think this new type needs an unique module identifier field in
> order to differentiate one module type from another (per-module type
> predicates).

It might make more sense to have a "type" field which holds
a Lisp_Object so we can trivially make it unique by using an object that
we just allocated.

>>> - how should modules be packaged?
>> As GNU ELPA packages, of course.
> Several headers are needed in order to build a module, and they have
> to be the one your current Emacs was built with (eg config.h).

Right, those headers need to be provided by Emacs.

> I think this means Emacs should copy those in the system include dir
> when installing.

If we let Emacs run the C compiler, it can trivially add the -I args
to specify where those headers are found.  This way they don't need to
be installed in the system's include dir (which is always a problem for
non-root users, and makes it more tricky to handle multiple installs of
different Emacs versions).

> Can we generate a config.h from a built emacs binary?

I don't think so.  But we can copy the config.h (and whichever other
include file we might need) when installing Emacs.

> Also the whole thing has to be portable (build commands, paths,
> ...).  Well it's going to be a nightmare to get right.

Yup!

> In the mean time I wrote a basic YAML parsing module [1] using
> libyaml.  You can read yaml from a file, a buffer or a string.
> I've tried to use direct access to lisp types (string, buffer) when
> reading yaml streams to prevent too much copying/type conversion
> overhead.  I haven't done much error checking yet so it's not very
> robust but it works:

Yay!


        Stefan