apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject RE: cvs commit: apr/test testdso.c
Date Thu, 05 Jun 2003 05:51:19 GMT
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.

Bill 


Mime
View raw message