httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Smith <>
Subject Re: [VOTE] Release Apache httpd 2.4.29 as GA
Date Fri, 20 Oct 2017 16:03:35 GMT
Well I got it now thanks mostly to your instructions Steefen, took 
awhile but once I put the the pieces together I see what needs to be done.

On 10/20/2017 1:44 AM, Steffen wrote:
> Nope, just double clicking Apache.dsw does now not create the xml 
> solution.  And without xml solution  httpd does not build (httpd 
> regression).
> 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).
> Ps.
> 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 <> 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.
>> 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;

View raw message