On Fri, Apr 8, 2011 at 11:59 AM, Guenter Knauf <fua...@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.
