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 @@ !ENDIF # Legacy default (and unwise alternative) for libapr-1.dll is libexpatMT -XML_PARSER="libexpat" +XML_PARSER=libexpat !IF "$(XML_PARSER)" == "libexpat" XMLOPT=XML_PARSER=$(XML_PARSER) !ELSE 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.
