I think I'd rather have apu 1.6.1 now without this (since we need it
now) and we can do this for 1.6.2 which will allow us to get any kinks
out (if any) while not under the gun. What do you think Steffen?
Also, if we're going in this direction (which I want to) is to just get
what's in trunk working in 1.6 with it's choice of expat or libxml2
which includes two additional files, one for using expat and one for
using libxml2, which I thought was the intent for 1.6 in the first place
IIRC, it just never happened.
On 9/27/2017 11:01 AM, William A Rowe Jr wrote:
This is now committed.
Would like to verify that this is working for our own win32 devs' build
preferences of expat 2.2.4, and glean any other feedback or suggestions
for improvement. I'm on to the cmake-side of the world for the moment,
I expect that won't be too rough, already collected suggestions for
compiling against expat..
On Wed, Sep 27, 2017 at 12:10 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
After deeper consideration, this was fundamentally wrong.
For those less familiar with the Win32 build, we failed to decouple
a "project" called "xml" which was, in fact, our idea of how expat
should be built.
That's unacceptable, as this missing file demonstrated. It shows
a lack of diligence in running tests (rather impossible to mix and
match between tests built on expat and those with httpd), It opens
us up to criticism for whatever "foolish" build flags we use versus
the recommended flags by the expat maintainers.
Already, apr-util has crypto libs, dbm providers, dbd providers, all
but one are external libraries maintained by external groups with
their own recommended build mechansims.
I will solve for visual studio Makefile.win builds with this;
# Provide the XML_PARSER argument after configuring LIB and INCLUDE with
# the expat path of the corresponding xml parser, e.g. libexpatMT to choose
# static, or libexpat (default) to choose the dynamic library for aprutil-1.dll
# (Static libaprutil-1.lib always presumes libexpatMT with XML_STATIC flag.)
#
# XML_PARSER="libexpat"
#
This will toggle the lib and the correct XML_STATIC setting. My theory
is as follows; libexpat.dll gets security updates. We shouldn't generally
be compiling it into a system like httpd. For a command line tool, e.g.
when libaprutil-1.lib (static) is used, libexpatMT is a fine choice, and
the user will have to compile that in as well. Wherever aprutil-1.dll is
being used, the libexpat.dll is the obvious right choice.
Anyone who knows Nick's efforts knows where this is leading, some time
in the future XML_PARSER=libxml2 can become a possibility.
Somehow we've all grown accustomed to trusting all the rest of these
third party projects and know how to set up LIB and INCLUDE search
paths, so this is simply not a hardship. Our custom build tooling for expat
must be jettisoned, we do so nowhere else. Unix can cope, so must Win32.
Cheers,
Bill
On Tue, Sep 26, 2017 at 6:17 PM, Gregg Smith <g...@gknw.net> wrote:
Feel free to do whatever you please with the cmake build. I just added the
new loadlibrary.c file to it is all so technically it is ready to go and apu
can be tagged.
On 9/26/2017 10:29 AM, William A Rowe Jr wrote:
This doesn't make sense to me; in unbundling, and providing a modern build
system, why are these sources mentioned?
Expat 2.2.x has it's own build schema, any attempt to replace expat's with
APR's seems misguided. Happy to stay mostly hands-off the mak/dsp as
this legacy tangle that users continue to consume, but the cmake was done
to turn windows builds into a conventional solution. The right fix there
is to
just switch compiling sources for linking to a library, and let that
library
maintainer do their thing.
So +1 to the dsp/mak change, but alternate CMakeFiles.txt feedback
to follow...
On Tue, Sep 26, 2017 at 10:13 AM, Gregg Smith <g...@gknw.net> wrote:
cmake should be as well. http://svn.apache.org/r1805330
On 9/26/2017 7:12 AM, William A Rowe Jr wrote:
Proceeding with the understanding that mak, and dsp files are OK on
-dev,
thank
you for the review in your schema, Steffen!
Cheers,
Bill
On Tue, Sep 26, 2017 at 4:00 AM, Steffen <i...@apachelounge.com> wrote:
No issues seen with building and running httpd with apr 1.6.3 and
apr-util
1.6.1
On Monday 25/09/2017 at 21:34, Steffen wrote:
No, used 1.6.2/1.6.0.
Tomorrow (already late here) I can try 1.6.3-dev and 1.6.1-dev.
Op 25 sep. 2017 om 20:52 heeft William A Rowe Jr <wr...@rowe-clan.net>
het
volgende geschreven:
Hi Steffen,
were you testing 1.6.x branches of apr (1.6.3-dev) and apr-util
(1.6.1-dev)?
Or the last released 1.6.2/1.6.0 flavors?
I'm reviewing here to avoid tagging something that won't build, if you
had already
done so for Windows, it would speed things up here.
Cheers,
Bill
On Mon, Sep 25, 2017 at 12:11 PM, Steffen <i...@apachelounge.com>
wrote:
On Windows it does not build out of the box.
Missing modules/core include for mod_watchdog.h in
mod_proxy_balancer.dsp/mak and libhttp.dsp/mak . Did not checked cmake.
Steffen
On Monday 25/09/2017 at 14:13, Jim Jagielski wrote:
The pre-release test tarballs for Apache httpd
version 2.4.28 can be found at the usual place:
http://httpd.apache.org/dev/dist/
I'm calling a VOTE on releasing these as Apache httpd 2.4.28 GA.
[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.
Vote will last the normal 72 hrs.
NOTE: The *-deps are only there for convenience.
Thx!
