apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: cvs commit: apr/test testdso.c
Date Thu, 05 Jun 2003 10:43:19 GMT


William A. Rowe, Jr. wrote:
> At 04:30 PM 6/4/2003, Sander Striker wrote:
> 
>>>From: Jeff Trawick [mailto:trawick@attglobal.net]
>>>Sent: Wednesday, June 04, 2003 10:06 PM
>>
>>>Sander Striker wrote:
>>>
>>>
>>>>It's about giving the user (an app developer) a tool you may not wish to
>>>>hand him.  This either forces him to write platform independend code, or,
>>>>makes him need to go to the ugly process of writing platform tests himself.
>>>
>>>I see an implication that if APR doesn't give the user a tool s/he will 
>>>be forced/encouraged/challenged to write platform independent code, and 
>>>that otherwise it would be a mess.
>>>
>>>Is my understanding of your point accurate?  IOW, do you believe that 
>>>for APR to provide a cleaner representation of such platform-specific 
>>>details will cause APR applications to be messier?
>>
>>Yes, that is a fair understanding.  I like your 'encouraged' better than
>>my 'forced', because it matches my thoughts.
>>
>>If people really need to know what platform they are compiling on, while
>>using APR, I think we haven't accomplished our goals with APR.  Feature
>>checks are one thing, platform checks are another.  IMHO, ofcourse.
> 
> 
> Bingo.  What the 'loadable module' extension is named based on platform
> would be really cruel (propagation of current code.)  Telling them that what
> any arbitrary platform's preference for a certain file semantic, locking
> mechanism or other 'behavioral' choice within APR would be goodness.
> 
> HPUX isn't alone in this respect (OS/X, Win32, we've demonstrated
> several examples) and this debate seems rather silly when the author
> is really asking WTF the extension aught to be to load a 'typical' dso.

Agree or don't agree with one philosophy or the other, but don't claim 
that this debate is centered on "WTF the extension aught to be" ;)

What it has to do with is whether APR is going to offer certain types of 
support for functional areas that APR doesn't try to solve.

If this discussion were really about the DSO extension, I might waste 
some breath pointing out that there is an optional prefix to worry about 
("lib" is the only one I've seen so far) as well as the extension, and 
that maybe instead of providing a couple of symbols to paste around a 
core filename we should allow the app to pass the libtool name (foo.la) 
to a function and get back the real library name (libfoo.so or foo.so or 
libfoo.dl or foo.dll or whatever).  But then I'd have to claim that I'm 
not so happy with the permanent attachment of libtool peculiarities to 
our API in such an obvious manner.  Let the user/app grab it from the 
.la file, or as I suggested before with apparent comical effect, if the 
app passes in foo.la, do the right thing under the covers by calling a 
non-externalized helper function that converts foo.la to libfoo.dl.


Mime
View raw message