On 10/19/2017 5:49 PM, William A Rowe Jr wrote:
On Thu, Oct 19, 2017 at 4:15 PM, Steffen <i...@apachelounge.com> wrote:
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.
set XML_PARSER=libexpat
devenv /useenv Apache.dsw
That should fix that. I read in that building in it's old location was
the only way plus a little tinkering the project to give it a libpath to
the lib. But then, that's what has to be done regardless of where expat
is. But your not getting this, there's no libpath: in the dsp/mak. That
missing and an include that still points to xml/expat/lib leads us to
believe we have to put it there, Though I knew better.
Now I can't speak for Steffen but the "putting expat in xml/ should have
clued you in to exactly what I said (on this very thing) at least enough
to ask for clarification with an open mind.
The only guidance we have is to look at the makefiles. The only thing to
latch onto to give us the slightest clue what you were thinking was the
one include, which remains /I "xml/expat/lib" ergo never removed or
modified to point someplace, anyplace where we are supposed to have it.
In httpd's case maybe srclib/*expat, I really don't care where, but we
need to know where.
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 don't read that into it. Again I don't care where it has to be so long
as we pick a place and stick to it and have a correct /I and /libpath:.
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.
Realistic to whom ... you? One man's patriot is another man's traitor.
This isn't a "use case" however, this is a "getting this all to build
case" period. We don't like upheaval but we do adapt, just we have no
guidance here to adapt to.
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.
Actually, 2.2.3 broke the build which I fixed. 2.2.4 just added a c99
factor for the older c89 versions of VC. I wouldn't call this a
regression here, it's broken at the apr level.
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;
https://wiki.apache.org/httpd/WindowsTrunkCompilation
There we go, last time I built APR2 I just put expat in a folder named
"expat" just outside apr's and it worked, because all the include and
libpath pointers were there to help me figure it out.