Re: Call for discussion: DLL handling
"J. Kean Johnston" <jkj(a)sco.com> writes:
Before going into the actual mechanisms, it is priudent to examine
WHY we think we need or want DSOs in XEmacs. It is already possible
to extend the editor using Lisp, and it is also possible to extend
it in C when you are compiling the editor. What makes DSOs
important is the fact that compiled C code can be selectively loaded
into the editor if and when it is needed. This will allow us to
(potentially) move parts of the editor into DSOs, thus making the
core editor smaller and faster to load, while retaining the ability
to extend its functionality. It is important to be able to write
some extensions in C, rather than Lisp, for speed purposes. While
the Lisp engine is fairly quick, there are cases (such as the HTML
parser) where a great benefit can be gained from writing it in C.
But not everyone wants to use their editor for a browser, so not
everyone should have their editor weighted down with an HTML parser.
Hence the need for DSOs.
Agreed. Note, however, that we will have to be very careful with the
third-party modules that are bound to be written. We must make it
clear that the C interface is open to changes, or otherwise we'll be
stuck.
What I have done is to flesh out dll.c to provide an actual working
implementation of DSO loading, using a variety of different models.
<offtopic>Have you looked at the second round of my remarks? I
haven't received a response from you?</offtopic>
CONST char *cemacs_mod_name = "whatever";
This variable is used to give the module a short tag or name, which is
used later in resolving inter-module dependancies. This should be
limited to 8 characters or less, and contain no spaces.
[...]
Note: perhaps these should be Lisp_Objects rather than char pointers.
But that would make them harder to initialize...
Anyway, we should be careful not to run into problems with Mule...
If any of these three strings is not present, the loader will reject
the module as invalid. The last check for module validity is a C
function, which is declared as:
int cemacs_init (int task, char *arg)
I would much prefer having several functions to having to build a big
cemacs_init() with a giant `switch' statement. What's wrong with
having more of them?
In the existing code, the developer uses the DEFUN() macro to define
a new C level subroutine. This results in a static structure being
set up and populated with static values. This model does not lend
itself well to supporting DSOs, due to the way PIC addresses are
stored in shared objects. (If you need more details on why this is
an issue, please feel free to contact me outside the scope of this
discussion. For now, please just accept my word that there is a
problem here).
Accepted. :-)
A third alternative (and one I have not implemented) is to have
variables and functions defined exactly the way they currently are,
using DEFUN(), DEFVAR_LISP() etc, with their comments in C as they
currently are, and then to extend the module build process to
include calls to make-docfile or some other suitable documentation
snarfer that can write out a special init.c
I would vote for this, only without the `init.c' file. For example,
the object build procedure might look like this:
obj-build foo.c
--> start documentation snarfer, snarf the code, add it to the
existing code and write it to foo-$$.c
--> gcc -c foo-$$.c -o foo.so ... oodles of flags ...
The biggest benefit of this approach is that the packages will be able
to choose between "loadable module" and "built-in" modes of operation
with a simple #ifdef. It will also allow us to support a
"--build-with-all" switch on systems that don't support dynamic
loading, such as Ultrix.
One of the biggest issues facing us is how we can co-exist at a
source code level with GNU Emacs.
I will refrain from commenting on this, except for "I don't care."
Kyle was definitely right about Stallman, us, and boat anchors.
Oh, and XEmacs is just as much Emacs as is FSF Emacs.
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.
I definitely vote for (C). It's the only sensible solution, as far
as I can tell.
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?
A new variable. Even if we make them conceptually similar to elisp
files, loadable modules are still implementationally quite different.
Should I send this stuff on to Stallman to look at too, and get him
in on the comment loop, or do we just make a choice and present
everything to him for integration into GNU Emacs feit acompli?
I think consulting with Stallman beforehand might be a waste of time
because Stallmacs handles some things differently (such as
docstrings), and I don't think he will have any understanding
whatsoever for our points of view.
I am "FSF-friendly", in that my copyright assignments are
on file at
the FSF, so I can appease that fear at the very least by assigning
copyright to them.
It's OK to have the contributions assigned. Mine are also assigned.
Anyway, thanks a bunch for your contributions and your code. It will
be very good to have them in 21.2. :-)
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
- Now what did we learn from this?
- I learned what my liver looks like!