Re: cvs commit: apr/test testdso.c

[Branko Čibej <br...@xbc.nu>]

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
>>>
>>>
>>> #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.

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/

Re: cvs commit: apr/test testdso.c

[Greg Marr <gr...@alum.wpi.edu>]

At 02:23 PM 6/4/2003, brane@xbc.nu wrote:
>Quoting Jeff Trawick <tr...@attglobal.net>:
> > Another factor is that not every portability issue affecting
> > applications that use APR is going to be adopted by APR as a 
> problem
> > that it can or should solve.  Some issues will always pop up for 
> certain
> > apps, and whether or not APR provides a clean way to check the 
> platform
> > isn't going to change that fact.
>
>So, what you're proposing is that APR provide mechanisms for people 
>to write platform-specific code? That's in direct conflict with our 
>mission to provice "predictable if not identical" behaviour across 
>platforms.

If you look at it as "providing a predictable and identical method of 
determining the platform at compile time" then it fully supports 
APR's mission.  When APR doesn't provide the functionality that the 
application needs, and it's pretty much a given that there is 
SOMETHING that APR hasn't covered yet, it can at least provide the 
mechanisms for determining the platform in a predictable fashion.

-- 
Greg Marr
gregm@alum.wpi.edu

Re: cvs commit: apr/test testdso.c

[Jeff Trawick <tr...@attglobal.net>]

brane@xbc.nu wrote:

> So, what you're proposing is that APR provide mechanisms for people to write
> platform-specific code?

APR already does that.

 > That's in direct conflict with our mission to provice
> "predictable if not identical" behaviour across platforms.

In conflict with or orthogonal to?

If APR implements feature foo across multiple platforms, it should have 
predictable if not identical behavior.

I don't see how that mantra applies to feature tests in the manner 
you're implying.

> (It also seems a bit weird, but maybe that's just me... :-)

Maybe its just me, but you make it sound as if this would suddenly offer 
the first feature that helps apps in their platform-specific code :)

Beyond platform symbols, which are supported currently in an 
inconsistent and clumsy manner (look at apr-config --cppflags on a few 
different boxes), APR defines other types of symbols that help 
applications do non-portable things in a somewhat cleaner manner than is 
often done without APR.  Much of the APR_HAVE_foo stuff has nothing to 
do with the APR API feature set.  But APR has figured that stuff out and 
is able to represent it, and it simplifies some tasks for interesting 
APR applications, so why not?  Are you planning to rip out everything in 
APR that is outside of or orthogonal to the "predictable if not 
identical behavior" goal?

Re: cvs commit: apr/test testdso.c

[br...@xbc.nu]

Quoting Jeff Trawick <tr...@attglobal.net>:

> Branko Ä&#65533;ibej wrote:
> 
> > 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.
> 
> Another factor is that not every portability issue affecting 
> applications that use APR is going to be adopted by APR as a problem 
> that it can or should solve.  Some issues will always pop up for certain
> apps, and whether or not APR provides a clean way to check the platform
> isn't going to change that fact.

So, what you're proposing is that APR provide mechanisms for people to write
platform-specific code? That's in direct conflict with our mission to provice
"predictable if not identical" behaviour across platforms.

(It also seems a bit weird, but maybe that's just me... :-)

Re: cvs commit: apr/test testdso.c

[Jeff Trawick <tr...@attglobal.net>]

Branko Čibej wrote:

> 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.

Another factor is that not every portability issue affecting 
applications that use APR is going to be adopted by APR as a problem 
that it can or should solve.  Some issues will always pop up for certain 
apps, and whether or not APR provides a clean way to check the platform 
isn't going to change that fact.

Re: cvs commit: apr/test testdso.c

[Jeff Trawick <tr...@attglobal.net>]

Branko Čibej wrote:
> Jeff Trawick wrote:
> 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.

Is APR a babysitter?

I would encourage people to use an APR define instead of

__hpux
__hpux__
__linux__
_AIX
SOLARIS2
__MVS__
WIN32
__whatevertheheck

in the rare places where such a check is useful. 
Lowest-common-denominator code doesn't need such a check.  Some other 
code does.  If people use it elsewhere that's their problem, and they 
were going to make the platform check anyway.  At least it might be more 
consistent and easier to locate in their code.

Re: cvs commit: apr/test testdso.c

[Jeff Trawick <tr...@attglobal.net>]

William A. Rowe, Jr. wrote:

> #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.

I don't see anybody claiming that the right solution for that problem is 
for APR to tell apps what the platform is.  This discussion started with 
my aggravation about the subtlety in checking for HP-UX.

>  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...)

Perhaps "clunky" or "error-prone" or "inconsistent" is more appropriate 
than "well defined."  A google search for a page with several of the 
compiler-defined symbols turned up only our sendrecv.c.

APR already defines platform symbols.  It just doesn't do it for every 
platform and it doesn't namespace-protect the symbols.  Either they 
should be ripped out or they should be straightened out for APR 1.0.

Re: cvs commit: apr/test testdso.c

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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
>>>>
>>>>
>>>> #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