On your first issue, there is no xml.mak. That was the APR
project's invention (mine, in fact) and was a bad, bad idea.
APR determined to expunge expat from our sources; the
whole shooting match - source files and build mechanisms -
and let the libexpat maintainers own their current sources and
build process. What confused things is that we didn't eliminate
this on Windows in time for our apr-util 1.6.0 release, and did
not communicate enough info about how to proceed further
in the 1.6.1 release.

Detailed posts like yours go a long way in resolving this lack
of communications.

In any case, httpd build was going to be broken, because httpd
also presumes it knows how how to build apr-util for httpd on
Windows. Poor assumption (and again, my bad.)

On your second issue, srclib/apr-util/xml/expat will no longer be
a "magical" path. Much like building pcre prior to building httpd,
building expat (along with each of the dbd, dbm and openssl
subcomponents) will remain prerequisite.

If it makes things easier at zero cost, the model is currently to
check out apr, apr-iconv and apr-util under the same directory
(e.g. a srclib/ or extern/ tree). That could be supported.

At the end of the day, LIB and INCLUDE paths are the only
sane way to link the various database runtime include and lib
paths, and expat should be treated no differently. If we slip
in a /libpath or /i relative to their ldflags or ccflags, that's fine...
in the absence of that path, the build continues with the normal
envvar paths.

If you were attempting to avoid passing that variable on the
*apr-util* nmake command line, this might be the issue...

--- Makefile.win (revision 1814737)
+++ Makefile.win (working copy)
@@ -87,7 +87,7 @@

 # Legacy default (and unwise alternative) for libapr-1.dll is libexpatMT
 !IF "$(XML_PARSER)" == "libexpat"

Quoted, that line in nmake makes no sense. In the unquoted form,
it aught to be treated as a default-but-overridable assignment. But
I still have testing to determine if this is the fix (I'm writing you from
the linux workstation, Windows hasn't been my default in years.)

Again, httpd Makefile.win needs to catch up for 2.4.x, but moreso,
it needs to stop trying to do what apr-util Makefile.win declares
how to do in httpd 2.5.0... and beyond.

Again thanks for the detailed report so we can chase this all down.

Reply via email to