New subject: Call for discussion: DLL handling

Tuesday, 20 October 1998

        "J. Kean Johnston" <jkj(a)sco.com&gt; 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. 
Another reason is to be able to import functionality of some existing
library into XEmacs by writing a thin glue layer in C that provides
lisp-level interface to the library.  (I am working on a program
analysis engine that will use XEmacs as its editor front-end in
precisely this manner)

[ ... ]

...
 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. 
Solution (A) is objectionable if you ever want to be able to optionally
compile same module together with XEmacs or separately into a DSO.  In
my work, however, knowing that I will never, ever want to compile my
library into XEmacs I don't mind using CDEFUN/CDEFVAR_LISP.

In light of the above, I believe the alternative (C) is better, although
I would much rather prefer (A), because it makes my "make" scripts less
complicated.

Another point to consider: I'd like to be able to download a standard
distribution of XEmacs (not the source) and be able to compile my
modules.  This means that the standard distribution must include the
appropriate .h headers as well as the appropriate incarnation of
"make-docfile".  Right now, cemacs.h depends on config.h generated
during build...

...
 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? 
My vote is for an OS-dependent directory.

Marat.

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Re: Call for discussion: DLL handling