Re: expat removed from APR project (Re: [VOTE] Release Apache httpd 2.4.28 as GA)
On Thu, Sep 28, 2017 at 10:57 PM, Greg Steinwrote: > On Wed, Sep 27, 2017 at 12:10 PM, William A Rowe Jr > 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)
On Thu, Sep 28, 2017 at 10:57 PM, Greg Steinwrote: > On Wed, Sep 27, 2017 at 12:10 PM, William A Rowe Jr > 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)
On Wed, Sep 27, 2017 at 12:10 PM, William A Rowe Jrwrote: >... > 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
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd 2.4.28 as GA)
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"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 > 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 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
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd 2.4.28 as GA)
On Wed, 27 Sep 2017 15:15:29 -0500 William A Rowe Jrwrote: > 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)
On Wed, Sep 27, 2017 at 2:12 PM, Steffenwrote: > 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)
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, Steffenwrote: > 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 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 > 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 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
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd 2.4.28 as GA)
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 Smithhet 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 >>> 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 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 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
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd 2.4.28 as GA)
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 Jrwrote: 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 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 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 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 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 wrote: On Windows it does not build out of the box. Missing modules/core include for
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd 2.4.28 as GA)
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 Jrwrote: > 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 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 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 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 >> 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 >> 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
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 Smithwrote: > 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 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 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 > 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 > 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: [VOTE] Release Apache httpd 2.4.28 as GA
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 Smithwrote: 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 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 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 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: [VOTE] Release Apache httpd 2.4.28 as GA
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 Smithwrote: > 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 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 >>> 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 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: [VOTE] Release Apache httpd 2.4.28 as GA
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, Steffenwrote: 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 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 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: Re: [VOTE] Release Apache httpd 2.4.28 as GA
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, Steffenwrote: > 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 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 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: Re: [VOTE] Release Apache httpd 2.4.28 as GA
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 Jrhet 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 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: [VOTE] Release Apache httpd 2.4.28 as GA
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 Jrhet > 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 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: [VOTE] Release Apache httpd 2.4.28 as GA
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, Steffenwrote: > 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! > >