On Tue, Oct 20, 1998 at 02:51:35PM +0200, Hrvoje Niksic wrote:
<offtopic>Have you looked at the second round of my remarks?
I
haven't received a response from you?</offtopic>
Hmmmm I thought I had
posted one. Yes, I have done the unwind_protect()
stuff and made things more Mule-friendly.
Anyway, we should be careful not to run into problems with Mule...
Yes I agree, but these variables have an extremely low-level requirement,
and are not *REALLY* meant to be user-visible, although the dll-list-modules
function will list the information. For this kind of highly specialized
purpose, is it really that much of an issue to use a char *? I'd prefer to
keep things as simple as possible.
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?
Absolutely nothing ... I just got lazy and only wanted to futz
about with
one function pointer :-)
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.
Producing foo-$$.c is no different to init.c except in
name ... you just
stated the same concept with a different file name :-) All that is important
is that the build process is suitably simple. What I was actually envisioning
was having the ellcc script be really smart, and build the documentation
.o behind the scenes at the time you invoke ellcc to create the .so. The
script would determine all of the object names, use that to pass on to
make-docfile, produce a temporary .c file which is compled and then linked
in with the .so.
Oh, and XEmacs is just as much Emacs as is FSF Emacs.
No, its
not. XEmacs is a useful editor with a future. FSF Emacs is ... well,
<politically_acceptable_mode>just the progenitor of a useful editor :-)
</politically_acceptable_mode>
--
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