apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: apr/test testdso.c
Date Wed, 04 Jun 2003 03:43:16 GMT
At 05:20 PM 6/3/2003, Branko Čibej wrote:
>Jeff Trawick wrote:
>> Joe Orton wrote:
>>> On Thu, May 29, 2003 at 07:38:29AM -0400, Jeff Trawick wrote:
>>>> trawick@apache.org wrote:
>>>>> trawick     2003/05/28 11:24:13
>>>>> Modified:    test     testdso.c
>>>>> Log:
>>>>> get testdso to work with the vendor's compiler on HP-UX, which
>>>>> defines a different symbol than gcc
>>>> or
>>>> or
>>>> something else
>>>> ??
>>> Not just to fix testdso
>> right, having a cleaner APR-ish way to check the platform is a general
>> nice-to-have and not part of the best solution for testdso
>> APR already defines and exports platform symbols on some platforms
>> anyway...  I wonder what apps actually use them
>I disagree. Encouraging the use of platform tests instead of feature
>tests is a very bad idea. Certainly, APR needs platform tests
>internally, but it should not expose platform knowledge directly to the
>user. Instead, the differences should be hidden in feature-test macros
>and constants; in this case, there should be a symbol for the (default)
>shared library name suffix.
>Imagine the mess if all APR users started to use APR_PLATFORM_IS_HPUX to
>decide the .so vs. .sl thing... this is exactly what APR is meant to avoid.


#define APR_DSO_DEFAULT_EXT ".so"
#define APR_DSO_DEFAULT_EXT ".sl"
#define APR_DSO_DEFAULT_EXT ".dll"
#define APR_DSO_DEFAULT_EXT ".dylib"

is the sort of thing we should be supporting.  No need for in-depth-knowledge
here.  We should *never* export flags like APR_PLATFORM_IS_WIZBANG.
That is a category, and there are plenty of *well defined* ways to determine
the platform (e.g. WIN32, HPUX or HPUX11, etc...)


View raw message