Nope, just double clicking Apache.dsw does now not create the xml
solution. And without xml solution httpd does not build (httpd
When I revert the Apache.dsw changes all fine, no headache and is not
complicated at all here.
I do not care where expat is located.
And cmake is not my way to go, still not getting a complete build
(please do not start the discussion cmake vs .dsp again, the cmake
quircks/limitations are pointed out several times).
For my personal use, when apr-util 1.6.1 is GA I revert also there the
expat related changes, till all is settled.
On Friday 20/10/2017 at 02:49, William A Rowe Jr wrote:
On Thu, Oct 19, 2017 at 4:15 PM, Steffen <i...@apachelounge.com>
I said before: In Apache.dsw is now project xml removed, it is not
building out of the box with current released apr-util. With coming
apr-util 1.6.1 it should be possible to build.
With the expat/xml changes in apr-util and httpd, it is now a hard job
for most win users to build.
Going with the “old” Apache.dsw and current apr-util, all looks
fine. The 2.4.28 regression mod_proxy loadfactor issue is solved and
it works now again.
Formal it is hard to say to go or not, so a +0.
By building out of the box, you mean building expat for you? That
behavior is by design, of course.
Reading your details on the other list, you are having problems with
the envvar, and attempted to build expat into its old location (and
further, are simply going to stay with the old xml.dsp logic not
provided by the expat project?)
Are you launching devenv with the /useenv flag with desired variables
set? It only promises to bring in your environment INCLUDE, LIB,
LIBPATH and PATH variables, so I'm not sure if it is a 100% solution.
It seems you and Gregg want to accomplish three different things,
Gregg thinks the obvious place for expat is under srclib/expat
(actually it unpacks as libexpat, shrug), you want to continue to
expand expat underneath srclib/apr-util/xml/, and I don't care, since
I build it entirely out-of-tree under the unpacked directory name,
configure and install into the target tree, and then set LIB and
INCLUDE as already documented for PCRE.
I'd like to support as many realistic use cases as possible while we
continue to clean up the segregation of httpd from apr[-util|-iconv],
so searching from the apr-util/ tree either xml/expat/lib or
../expat/lib seems reasonable to me.
Doesn't seem this is a regression, unless something that was working
quit working, and the build didn't work before with expat 2.2.4, so
that isn't in question.
Looking for good solutions here to help users accomplish builds in a
variety of ways without overcomplicating our project's long term
maintenance (extra headaches during httpd-2.4 are expected, of
course.) This basic logic should be working, for example;