process.h

[Jeff Trawick <tr...@gmail.com>]

On Fri, Apr 8, 2011 at 11:29 AM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 4/8/2011 9:07 AM, Guenter Knauf wrote:
>> Am 08.04.2011 08:02, schrieb William A. Rowe Jr.:
>>> Jeff, I've lost your thread, probably because it's half at httpd.
>>>
>>> Just so you know, I did get to spend my hours yesterday and today on 2008R2
>>> with Visual Studio 2010 - mostly on the tasks of rebuilding a VM to which
>>> I had lost the admin password (damn 'password constraints').
>>>
>>> I would like to spend some time tomorrow and Saturday morning wrapping up
>>> all our work, I have Steve's work ready to commit and will at least ensure
>>> Bert's suggestions are adopted, if not a wholesale fix to //unc/vol issues.
>>>
>>> Guenter, you have also make a ton of adjustments - are your changes ready
>>> to fly?
>> Regarding netware:
>> yes sir - all builds nicely, and I can now compile NetWare targets on Linux for all
>> APR/APU and httpd HEAD/2.2.x versions.
>>
>> Regarding windows:
>> I would like to cleanup some stuff in apr:
>> http://people.apache.org/~fuankg/diffs/apr_cleanup.diff
>> it makes no sense to me that we duplicate HAVE_* in arch/apr_private.h for which we have
>> already APR_HAVE_* in apr.h[w] ...
>
> AIUI, Autoconf duplicates these, no?  If not, I generally agree, however
> you didn't look sideways with this proposal, for example,
> strings/apr_strings.c:#ifdef HAVE_STDLIB_H just to name one example.
>
> And I also wouldn't agree with including process.h to every consumer of apr,
> adding new system headers to apr.h needs strong justification.  Adding this
> under the arch/private generic header would be fine, compilers are fast enough
> these days that it shouldn't be a colossal hit on build time.

process.h has a cute history

1.4.x:

APR_HAVE defined in apr.hw/apr.h.in; the include is performed in
apr.hw if defined

so apr.h.in needs to add the include if defined for same app
experience with the two build systems

trunk:

you removed the APR_HAVE_ and include from apr.hw; Günther added the
APR_HAVE back to apr.h.in, so they're out of sync and need to be fixed

fine with me not to include it everywhere, but the APR_HAVE has been
useful (I think httpd uses that)

APR_WANT_GETPID for apr_want.h is the more appropriate interface for
APR 2, but that still needs a visible APR_HAVE_PROCESS_H

Re: process.h

[Jeff Trawick <tr...@gmail.com>]

On Fri, Apr 8, 2011 at 11:59 AM, Guenter Knauf <fu...@apache.org> wrote:
> Am 08.04.2011 17:45, schrieb Jeff Trawick:
>>
>> process.h has a cute history
>>
>> 1.4.x:
>>
>> APR_HAVE defined in apr.hw/apr.h.in; the include is performed in
>> apr.hw if defined
>>
>> so apr.h.in needs to add the include if defined for same app
>> experience with the two build systems
>
> hehe, ans sorry I didnt dig that up self ...
>
>> trunk:
>>
>> you removed the APR_HAVE_ and include from apr.hw; Günther added the
>> APR_HAVE back to apr.h.in, so they're out of sync and need to be fixed
>>
>> fine with me not to include it everywhere, but the APR_HAVE has been
>> useful (I think httpd uses that)
>
> so then my patch although intuitive without knowing history looks more like
> forward patch then ... :-)
>
>> APR_WANT_GETPID for apr_want.h is the more appropriate interface for
>> APR 2, but that still needs a visible APR_HAVE_PROCESS_H
>
> what's that bad to include an offical system header for one platform when we
> have it? If we would agree to make it equal with all 1.x / 2.x APR versions
> to include it from apr.h then we could axe a lot of 'ifdef
> APR_HAVE_PROCESS_H' from httpd trunk as well as 2.2.x ...

Including the headers which aren't required by the public apr headers
themselves is an endless chore (always another system header of
interest to somebody), may lead to unnecessary conflicts with user
code, isn't really the sort of feature that apr provides other than as
a side effect (e.g. apr_network_io.h may pull in network-related
system headers), may slow down builds of user code.

Re: process.h

[Guenter Knauf <fu...@apache.org>]

Am 08.04.2011 17:45, schrieb Jeff Trawick:
> process.h has a cute history
>
> 1.4.x:
>
> APR_HAVE defined in apr.hw/apr.h.in; the include is performed in
> apr.hw if defined
>
> so apr.h.in needs to add the include if defined for same app
> experience with the two build systems
hehe, ans sorry I didnt dig that up self ...

> trunk:
>
> you removed the APR_HAVE_ and include from apr.hw; Günther added the
> APR_HAVE back to apr.h.in, so they're out of sync and need to be fixed
>
> fine with me not to include it everywhere, but the APR_HAVE has been
> useful (I think httpd uses that)
so then my patch although intuitive without knowing history looks more 
like forward patch then ... :-)

> APR_WANT_GETPID for apr_want.h is the more appropriate interface for
> APR 2, but that still needs a visible APR_HAVE_PROCESS_H
what's that bad to include an offical system header for one platform 
when we have it? If we would agree to make it equal with all 1.x / 2.x 
APR versions to include it from apr.h then we could axe a lot of 'ifdef 
APR_HAVE_PROCESS_H' from httpd trunk as well as 2.2.x ...

Gün.