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