Re: Call for discussion: DLL handling

Tuesday, 20 October 1998

        "J. Kean Johnston" <jkj(a)sco.com&gt; writes:

...
 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. 
I must have missed it, sorry.  But that is excellent news.  Where can
I find the latest incarnation of your code?

...
 > 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. 
OK, if they are not user-visible, char * is fine.

...
 > 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 :-) 
Let's please use separate functions then.  If we do, we also get the
convenience of each function receiving the appropriate number of
arguments, etc.

...
 > 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 ... 
Oh.  OK, sorry for misunderstanding you.  :-)

...
 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. 
Yup.

...
 > 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> 
Heh, you're right.  :-)  But we still shouldn't promote the notion
that #ifdef EMACS is FSFmacs only, and #ifdef XEMACS is XEmacs-only.
It's Stallmanism.

-- 
Hrvoje Niksic <hniksic(a)srce.hr&gt; | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
We are all just prisoners here of our own MAKEDEV.

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