Re: Call for discussion: DLL handling
J. Kean Johnston wrote:
[general rationale agreed with and snipped]
int cemacs_init (int task, char *arg)
{
switch (task)
{
[cases snipped]
}
return 0;
}
Shouldn't this default to returning non-zero? The idea of using a single
cemacs_init() with three task codes instead of, say, separate
load_module(), syms_of_module() and vars_of_module() is, I guess, to
provide extensibility. It may be important for the caller to know
whether this module really understands a new task code or whether it is
just falling out of the switch statement.
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.
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.
[big snip]
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.
One last thing. Do we want shared objects loaded from the normal Lisp
load
path, or do we want to set up a new variable to contain the shared objects,
perhaps having the default be in the OS dependant directory?
Shared objects will be platform-dependant binaries, so they shouldn't
live in load-path. Putting them in exec-directory may be the safest
thing to do because this is not shared between XEmacs versions. Perhaps
a new lisp variable is the right extensible answer.
If anyone has not followed the previous threads between Hrjove and
myself,
and you have not seen the documentation or dll.c implementation and other
patches, please let me know and I will put them up somewhere for people to
FTP and peruse.
Does your post of 16/09/98 contain your latest code?
[more snipped]
I haven't seen anything that can't work under MS Windows (which is my
particular concern) without very minor tweaking, but I will try it and
report back.
Jonathan.
--
Jonathan Harris | jhar(a)tardis.ed.ac.uk
London, England | Jonathan.Harris(a)symbian.com