Re: svn commit: r1854603 - in /apr/apr-util/branches/1.7.x: build/apu-conf.m4 build/xml.m4 configure.in include/apu.h.in include/apu.hw include/apu.hwc xml/NWGNUmakefile xml/apr_xml.c xml/apr_xml_expat.c xml/apr_xml_internal.h xml/apr_xml_libxml2.c

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

On Sat, Mar 30, 2019 at 8:32 AM Rainer Jung <ra...@kippdata.de> wrote:

> Hi Nick,
>
> Am 27.03.2019 um 23:42 schrieb Nick Kew:
> >
> >> On 27 Mar 2019, at 17:55, Rainer Jung <ra...@kippdata.de> wrote:
> >>
> >> This breaks 1.7 apu compilation using non-system expat for me. The
> expat detection sets INCLUDES but during compilation INCLUDES isn't used
> anywhere, so expat.h can't be found.
> >
> > OK, I need to return to that.  Thanks for the reminder!
> >
> > Does trunk compile for you in the same circumstances?
> > This is supposed to be a backport!
>
> Trunk is APR which adds INCLUDES to EXTRA_INCLUDES and uses those during
> build. APU doesn't use EXTRA_INCLUDES anywhere but uses the
> APRUTIL_PRIV_INCLUDES and APRUTIL_INCLUDES variables, none of which the
> expat flags gets added to. dbd seems to use APRUTIL_PRIV_INCLUDES, all
> other dependencies seem to use APRUTIL_INCLUDES ...
>

Confirmed, the odd nature of needing to include not "include/" but
"include/libxml2/" to pick up "libxml/" (blame that bizzare quirk on their
maintainers) means that what has been working perfectly well for
speculative apr-2 builds is broken in apr-util/branches/1.7.x/. Because I
throw all of the dependencies into one target tree, I'd rarely pick up on
such errors because some other component's lib/ and include/ tree
resolution solves it for the few broken ones.

Is anyone a commit away from a fix before I attempt to help untangle? This
has been dangling breakage for some time now.