apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Clean up of DSO autoconfizification
Date Wed, 18 Apr 2001 22:48:27 GMT
On Wed, Apr 18, 2001 at 02:56:02PM -0700, rbb@covalent.net wrote:
> On Wed, 18 Apr 2001, Wilfredo Sanchez wrote:
> 
> >    I don't like how we detect whether DSO support should be enabled by
> > testing for the possible implementation methods, and then rather than
> > remembering which we found, we have all this #if THIS_OS crap all over
> > dso/unix/dso.c.  If we found dlfcn or shl or whatever, that should be
> > what we conditionalize on, and maybe have per-OS mangling for the
> > variant dlopen() hoo-hah out there.
> >
> >    So here is a patch to define macros for the found support for dynamic
> > loading.  I imagine that I picked stupid names for the macros, and would
> > welcome a correction.  Otherwise, this seem OK?
> 
> +1.  The old code was lifted out of 1.3 directly.  This is much easier to
> understand.

+1, much better.

I used an even cleaner solution in Python about a year and a half ago. At
config time, I selected one of N files to compile and link in. Each module
implemented a specific method. Here are the modules that Python has:

dynload_aix.c   dynload_hpux.c  dynload_os2.c    dynload_win.c
dynload_beos.c  dynload_mac.c   dynload_shlib.c
dynload_dl.c    dynload_next.c  dynload_stub.c

That last is when dynload isn't available on a platform. It all works quite
well, and the above kind of structure would actually work reasonably well in
our setup.

But hey... Let's go with Fred's patch now. The above is work that hasn't
been done, and I'm not volunteering right now, so forget it :-)  I just
wanted to put out the brain-bug in case somebody wants to get motivated.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message