Re: Call for discussion: DLL handling
On Tue, Oct 20, 1998 at 01:04:09AM +0100, Jonathan Harris wrote:
Actually, I think that separate load_module(), syms_of_module() and
vars_of_module() functions would be prettier and would not be
significantly harder to implement in cemacs_load_module(). Extensibility
can always be provided by the caller checking for the existence of newer
functions by name in the module.
*nod* that is an option, and yes, return a failure
by default would be a
Good Thing. Its no big deal at all to use actual function names for the
different tasks at all. The biggest reason I used one function with multiple
task codes was that I only have one function pointer to maintain. Call me
lazy :-)
BTW, I understand where the "cemacs" in various variables
and functions
comes from, but I think that "emacs_module" or something might be more
descriptive.
*nod* to this too. Nothing is cast in concrete, especially not the
symbol
names. Something short than emacs_module as a prefix is preferable though.
> To summarise, the three choices are:
> (A) Use DSO specific macros such as CDEFUN(), CDEFVAR_LISP() etc.
> (B) Use the existing DEFUN() and DEFVAR_() macros and have documentation
> handled during task code 3, or
> (C) Keep everything exactly as it is and extend the DSO build scripts to
> snarf the documentation strings correctly and construct a .c file.
Option (B) is yuck. Handling task code 3 is horrible because it
separates the comment from the code and because it imposes unnecessary
burdens on the implementor. I don't see how it is possible to make this
option not yuck.
Option (C) looks to me like a potential winner, at the expense of a
little complication in the build, but I personally don't find option (A)
objectionable.
I like option (C) too, but I forgot to mention a 4th option. We *COULD*
change all the existing calls to DEFUN() to use a C-like string, modify
make-docfile to snarf that syntax, and then have suitable #ifdef DLL_EMACS
(or some other suitable manifest constant) in the macro expansion that
will ignore the string for normal in-emacs calls and populate the right
structure in dynamic module calls. This is a far more pervasive change,
in that it will affect every source module, but it *IS* clean.
Does your post of 16/09/98 contain your latest code?
I am not
sure, I have deleted it.
--
J. Kean Johnston | "Every day, computers are making people easier
Engineer, SPG | to use" -- Source unknown.
Santa Cruz, CA +----------------------------------------------------------
Tel: 831-427-7569 Fax: 831-429-1887 E-mail: jkj(a)sco.com