You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2017/09/27 17:10:59 UTC
expat removed from APR project (Re: [VOTE] Release Apache httpd
2.4.28 as GA)
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 <gl...@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 <gl...@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 <in...@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 <in...@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!
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd
2.4.28 as GA)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
I'm sorry so much context was lost to dev@. PMC voted to apply
reply-to-list context for dev@ many moons ago. Nick, would you help me to
work with infra to ensure this is accomplished by a week from Friday?
On Sep 27, 2017 13:58, "Gregg Smith" <gl...@gknw.net> wrote:
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.
I think this is where several conversation forks diverged from the list but
to reiterate,
* Apr-util 1.6.0 was not directly usable by a number of win32 builders, in
short, it wasn't actually a win32 compatible release.
* APR PMC voted to evict all aspects of the expat project from our
maintenance, ceding ownership back to that now-rather-active project. This
includes .c source, and build.
* Message telegraphed in CHANGES etc that expat must be independently
obtained and *built* by the consumer.
* On win32 this didn't entirely happen, my commits of today remedy this.
Partly my bad that I was evaluating my own fork, which caused expat to be
built independently for the past 15+ years, but was not generally available
to consumers.
AIUI these are the facts, there are likely more data points and much
further conjecture, and much inconvenience. Let's continue this on this
public forum and avoid reply to sender, till we can get MLM mechanics
corrected.
Sorry for bad formatting, blame Google Gmail app team. Even Linus thinks it
is bollocks.
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 <gl...@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 <gl...@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 <in...@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 <
>>>>>>> wrowe@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 <in...@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!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd
2.4.28 as GA)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Sep 27, 2017 at 2:12 PM, Steffen <in...@apachelounge.com> wrote:
> Yes, 1.6.1 for next httpd 2.4.28.
>
> I want to go now for libxml2 and forget expat. We have already libxml2.dll
> in the distro.
>
> We need also changes in the httpd dsp/mak/dsw/win files ?
Answering your question directly... the xml dir must be refreshed with
the trunk flavor, and apr_xml_libxml2.c is used in place of apr_xml_expat.c
In our overall build scheme, on cmake we should detect them, in any old
style build schema we should toggle the choice through a nmake variable.
apr_xml_libxml2.c and apr_xml_expat.c are both included in the build,
config variables APU_USE_LIBXML2 (true) APU_USE_EXPAT (false)
need to be defined and control which source is alive.
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd
2.4.28 as GA)
Posted by Nick Kew <ni...@apache.org>.
On Wed, 27 Sep 2017 15:15:29 -0500
William A Rowe Jr <wr...@rowe-clan.net> wrote:
> I don't believe we can do libxml2 until the release of 1.7.0, the
> supporting logic that Nick committed is sitting in trunk/2.0 - It's
> not on my agenda today, but after 1.6.1/1.6.3, sure.
>
Indeed, I realised it was only in trunk while we were in the 1.6
release push. I think we had enough delays in that, without the
risks of another fairly substantial backport!
I guess now 1.7 makes a good target for it. It's on my agenda,
insofar as I have one these days.
--
Nick Kew
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd
2.4.28 as GA)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
I don't believe we can do libxml2 until the release of 1.7.0, the supporting
logic that Nick committed is sitting in trunk/2.0 - It's not on my agenda today,
but after 1.6.1/1.6.3, sure.
Back to the subject at hand, I tested using the expat and expat_static
projects, making libexpat.dll/.lib and libexpatMD.lib respectively. That
is what is recognized by the Makefile.win file right now.
Building expat's cmake flavor doesn't appear to result in shared+static,
which is a little unusual. So forcing a -D BUILD_shared=OFF in the
cmake invocation delivers the classic XML_STATIC libs. with the
expat.lib name. Here, building apr with XML_PARSER=expat does
deliver the expected results, and is what httpd would want for all
of the support/* tools which we compile statically against apr.lib.
On Wed, Sep 27, 2017 at 2:12 PM, Steffen <in...@apachelounge.com> wrote:
> Yes, 1.6.1 for next httpd 2.4.28.
>
> I want to go now for libxml2 and forget expat. We have already libxml2.dll
> in the distro.
>
> We need also changes in the httpd dsp/mak/dsw/win files ?
>
>
> Op 27 sep. 2017 om 20:58 heeft Gregg Smith <gl...@gknw.net> het volgende
> geschreven:
>
> 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 <gl...@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 <gl...@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 <in...@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 <in...@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!
>
>
>
>
>
>
>
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd 2.4.28 as GA)
Posted by Steffen <in...@apachelounge.com>.
Yes, 1.6.1 for next httpd 2.4.28.
I want to go now for libxml2 and forget expat. We have already libxml2.dll in the distro.
We need also changes in the httpd dsp/mak/dsw/win files ?
> Op 27 sep. 2017 om 20:58 heeft Gregg Smith <gl...@gknw.net> het volgende geschreven:
>
> 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 <gl...@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 <gl...@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 <in...@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 <in...@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!
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd
2.4.28 as GA)
Posted by Gregg Smith <gl...@gknw.net>.
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 <gl...@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 <gl...@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 <in...@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 <in...@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!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd
2.4.28 as GA)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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 <gl...@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 <gl...@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 <in...@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 <in...@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!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd
2.4.28 as GA)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Sep 28, 2017 at 10:57 PM, Greg Stein <gs...@gmail.com> wrote:
> 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.
>
>
> Strictly speaking, the xml module is an API that creates a memory-efficient
> DOM of an XML document, so that mod_dav could easily consume it. The API
> originated from mod_dav's needs.
Indeed, that's how I've understood it.
> Another way to view it, is that Expat is a streaming/callback model, but
> mod_dav needed a random-access model. The xml code and API is that bridge.
Right.
>> 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.
>
> More background: Expat *source* was added to the apr-util library back in
> 1999 or 2000 or somesuch. At the time, the library wasn't normally packaged
> and easily available. The choice was made to include it, to help downstream
> users in a "batteries included" form, but have enough autoconf magic to also
> use a pre-installed Expat package.
And wasn't generally distributed in any mainline linux distribution (ignoring
Win32 entirely)...
> Nowadays, it makes no sense to keep carrying around the Expat source.
>
> Regarding whether to use Expat and/or libxml under the API covers ... I
> don't have any insight or opinion on that. ... I just have insight on the
> API and Expat's presence cuz, well, it's my fault :-)
Not fault. It was a good choice. libxml2 is a suitable replacement. Our
abstraction wasn't serious, because we choose to bundle it base on the
then-current maintenance.
Now, there is a serious community around the maintenance of the codebase,
and it is and should be "out of our hands". In some small measure, expat
grew due to apr's adoption. But it is not our place to be everything to
everybody. Let the maintainers promulgate their codebase now, we are
simply consumers.
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd
2.4.28 as GA)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Sep 28, 2017 at 10:57 PM, Greg Stein <gs...@gmail.com> wrote:
> 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.
>
> Strictly speaking, the xml module is an API that creates a memory-efficient
> DOM of an XML document, so that mod_dav could easily consume it. The API
> originated from mod_dav's needs.
>
> Another way to view it, is that Expat is a streaming/callback model, but
> mod_dav needed a random-access model. The xml code and API is that bridge.
Actually, you are confusing the xml win32 project that is a specific
build of the old
1.95 expat for static linkage with the apr_xml_*() API... so the 'xml'
project that
had to go away was the one in conflict with the expat 2.2.x project.
Think in terms
of using the 12 year old autoconf/makefile.in on an n+1 release of any library.
>> 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.
>
> More background: Expat *source* was added to the apr-util library back in
> 1999 or 2000 or somesuch. At the time, the library wasn't normally packaged
> and easily available. The choice was made to include it, to help downstream
> users in a "batteries included" form, but have enough autoconf magic to also
> use a pre-installed Expat package.
... as well as our own expat .dsp files for dynamic and static
linkage, to mirror
what we were doing for apr and httpd. Back in those days, there wasn't great
windows build support for expat on win32.
> Nowadays, it makes no sense to keep carrying around the Expat source.
>
> Regarding whether to use Expat and/or libxml under the API covers ... I
> don't have any insight or opinion on that. ... I just have insight on the
> API and Expat's presence cuz, well, it's my fault :-)
And mine - for the win32 schema.
One more important note, AIUI subversion still requires direct access to the
expat API, at this time libxml2 would not be a drop-in-replacement for the
mod_dav_svn and other binaries from the subversion project.
Unless I'm misunderstanding that state of affairs?
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd
2.4.28 as GA)
Posted by Greg Stein <gs...@gmail.com>.
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.
>
Strictly speaking, the xml module is an API that creates a memory-efficient
DOM of an XML document, so that mod_dav could easily consume it. The API
originated from mod_dav's needs.
Another way to view it, is that Expat is a streaming/callback model, but
mod_dav needed a random-access model. The xml code and API is that bridge.
>...
> 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.
>
More background: Expat *source* was added to the apr-util library back in
1999 or 2000 or somesuch. At the time, the library wasn't normally packaged
and easily available. The choice was made to include it, to help downstream
users in a "batteries included" form, but have enough autoconf magic to
also use a pre-installed Expat package.
Nowadays, it makes no sense to keep carrying around the Expat source.
Regarding whether to use Expat and/or libxml under the API covers ... I
don't have any insight or opinion on that. ... I just have insight on the
API and Expat's presence cuz, well, it's my fault :-)
Cheers,
-g