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: >>> >>>> [EMAIL PROTECTED] 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 >>>> >>>> >>>> #if APR_PLATFORM_IS_HPUX >>>> or >>>> #if APR_PLATFORM == APR_PLATFORM_HPUX >>>> 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.
++1. #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...) Bill
