Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 23513 invoked by uid 500); 18 Apr 2001 22:46:17 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 23486 invoked from network); 18 Apr 2001 22:46:13 -0000 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 18 Apr 2001 15:48:27 -0700 From: Greg Stein To: APR Developers Subject: Re: Clean up of DSO autoconfizification Message-ID: <20010418154827.L31832@lyra.org> Mail-Followup-To: APR Developers References: <200104182150.RAA24040@melbourne-city-street.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from rbb@covalent.net on Wed, Apr 18, 2001 at 02:56:02PM -0700 X-URL: http://www.lyra.org/greg/ X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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/