Re: mod_brotli in 2.4.x is missing a few Makefile changes
On Apr 30, 2017 12:27 PM, "Jan Ehrhardt"wrote: Gregg Smith in gmane.comp.apache.devel (Sun, 30 Apr 2017 08:54:34 -0700): >On 4/30/2017 5:36 AM, Jan Ehrhardt wrote: > >> The problem with CMake is that it does not build all things, that AL and >> AH put in their distributions. CMake will build Apr 1.6 and Apr-util >> 1.6, including apr_crypto_openssl-1.dll (1.0.2 or 1.1.0) in one go. > >Yes Jan I realize this but "recommend" does not mean "you must." No, but the point is that you cannot rely on CMake alone, if you want iconv support. You must use the dsp's or the msvc makefiles. As much as I hated the idea of persisting apr-iconv over the BSD Citrus sources, I've found no time to port those to Windows. Better we fix this gap of CMake support and release another 1.2.x apr-iconv in the interim. Will look at this Monday.
Re: mod_brotli in 2.4.x is missing a few Makefile changes
On Apr 29, 2017 9:19 PM, "Gregg Smith"wrote: On 4/29/2017 5:19 PM, Gregg Smith wrote: Bill, viewing the complete thread your reasoning here should have > precluded this discussion years ago when pcre went to cmake, so at or > before 2.4.0. After all, it's the only way to build pcre which is a hard > requirement, not soft like brotli. > > I guess I didn't see it all. I see now where your reasoning is as far as doing it now and not before. I am not clear either; I'm putting forward a rationale for simplifying our repository in 2.5.x+++ and not actually suggesting we remove any module. If we add modules to 2.4.x in subversion releases, and a given module requires CMake, my comment was that it's possible for us to consider supporting this only under cmake and not under the dsw/dsp build schema. I see no majority as 3 do, 3 do not (if I include expat). This is assuming nghttp2 fixed the cmake problem I had on windows. I would think so as a long time and many versions have come since then. I'm still against removal/shorting legacy yet not against recommending cmake. Again my comments are largely about what comes next. At the time 2.4.0 was prepared, there were a number of archaic pcre options. That won't be the case when 2.5.0 beta is tagged. I've always been against breaking changes during subversion point bumps, and lessening the dsw/dsp/mak support would be one such change if it happened in any 2.4.x release. Because there is no mod_,brotli in 2.4.25, including or excluding it from one schema or another is not a breaking change by any measure. There is one and only one justification for the unsupported dsw/dsp format and that is simply that MS broke the ability to export .mak files when introducing VcProj/sln solutions. I will support, if a majority (or significant minority) insists on VcProj files within an sln that cannot be correctly generated under CMake. I refuse to persist with dsp/dsw files because CMake can emit these on its own. There is no surviving supported tool that speaks dsw/dsp and such files must go away as we roll out a new 2.5.x for consideration.
Re: mod_brotli in 2.4.x is missing a few Makefile changes
Gregg Smith in gmane.comp.apache.devel (Sun, 30 Apr 2017 08:54:34 -0700): >On 4/30/2017 5:36 AM, Jan Ehrhardt wrote: > >> The problem with CMake is that it does not build all things, that AL and >> AH put in their distributions. CMake will build Apr 1.6 and Apr-util >> 1.6, including apr_crypto_openssl-1.dll (1.0.2 or 1.1.0) in one go. > >Yes Jan I realize this but "recommend" does not mean "you must." No, but the point is that you cannot rely on CMake alone, if you want iconv support. You must use the dsp's or the msvc makefiles. -- Jan
Re: mod_brotli in 2.4.x is missing a few Makefile changes
On 4/30/2017 5:36 AM, Jan Ehrhardt wrote: The problem with CMake is that it does not build all things, that AL and AH put in their distributions. CMake will build Apr 1.6 and Apr-util 1.6, including apr_crypto_openssl-1.dll (1.0.2 or 1.1.0) in one go. Yes Jan I realize this but "recommend" does not mean "you must." The http project has recommended people use 2.4.x since it came out. We did not force people from using 2.2.x did we?
Re: mod_brotli in 2.4.x is missing a few Makefile changes
Jan Ehrhardt in gmane.comp.apache.devel (Sun, 30 Apr 2017 14:36:57 +0200): >*.mak files in apr-util + the Makefile.win's in apr-util\(ces|css) *.mak files in apr-iconv + the Makefile.win's in apr-iconv\(ces|css)
Re: mod_brotli in 2.4.x is missing a few Makefile changes
Gregg Smith in gmane.comp.apache.devel (Sat, 29 Apr 2017 17:19:03 -0700): >I have no problem with "recommending" folks use cmake, none at all. I >find it to be a pain in the backside but that's just me. Others may >share this but I will not stand in the way of simply "recommending" it. >I'm actually for it so there are less folks new to building httpd having >problems because of all the quirks the different VC versions have. The problem with CMake is that it does not build all things, that AL and AH put in their distributions. CMake will build Apr 1.6 and Apr-util 1.6, including apr_crypto_openssl-1.dll (1.0.2 or 1.1.0) in one go. CMake will also build the Apache binaries in another go, but nothing of Apr-iconv. So apriconv-1.lib, libapriconv-1.lib/dll and all of the 200+ so-files in apache24\bin\iconv will not be built by CMake. You will have to use Apache.dsw or srclib\apr-util\aprutil.dsw or the *.mak files in apr-util + the Makefile.win's in apr-util\(ces|css) to build the iconv binaries. -- Jan
Re: mod_brotli in 2.4.x is missing a few Makefile changes
On 4/29/2017 5:19 PM, Gregg Smith wrote: Bill, viewing the complete thread your reasoning here should have precluded this discussion years ago when pcre went to cmake, so at or before 2.4.0. After all, it's the only way to build pcre which is a hard requirement, not soft like brotli. I guess I didn't see it all. I see now where your reasoning is as far as doing it now and not before. I see no majority as 3 do, 3 do not (if I include expat). This is assuming nghttp2 fixed the cmake problem I had on windows. I would think so as a long time and many versions have come since then. I'm still against removal/shorting legacy yet not against recommending cmake.
Re: mod_brotli in 2.4.x is missing a few Makefile changes
On 4/28/2017 9:35 AM, Jan Ehrhardt wrote: William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03 -0500): You might have missed my thought here... suggesting that the CMake not-so-experimental build become recommended for users who want to build all the modules in one go including the new mod_brotli. People like Steffen, Gregg and me disagree with you on making CMake the only way for building Apache and all the modules in one go. Maybe we have an English->Dutch translation error? I have no problem with "recommending" folks use cmake, none at all. I find it to be a pain in the backside but that's just me. Others may share this but I will not stand in the way of simply "recommending" it. I'm actually for it so there are less folks new to building httpd having problems because of all the quirks the different VC versions have. I do however have a problem with any thought or discussion of removing or shorting modules in the legacy build up until such time as it really is impossible to build with it or simply goes stale because of lack of will to keep it up to date which as of now has not yet happened. Bill, viewing the complete thread your reasoning here should have precluded this discussion years ago when pcre went to cmake, so at or before 2.4.0. After all, it's the only way to build pcre which is a hard requirement, not soft like brotli. It sounds like you attempted to export mod_brotli.dsp to a vcproj all on it's own which has never been possible. It is perfectly possible. That is how I added mod_fcgid and now mod_brotli to my existing Apache 2.4.25 sln. Convert to vcproj (VC9) or vcxproj (VC11/VC14), add the x64 configuration, add the vc(x)proj as an existing project to Apache.sln. I am doing the same thing when mod_http2 changes the headers or sources. For 2.4.next I will convert Apache.dsw once again and add mod_fcgid afterwards.
Re: mod_brotli in 2.4.x is missing a few Makefile changes
On Apr 28, 2017 2:40 PM, "Steffen"wrote: cvtdsp.pl is not a hassle, just a easy step. Quote: you should not need cvtdsp.pl -2005 with VC14. They fixed this in the conversion. Terrific, this is verified?!? Otherwise there is no requirement for a Windows build to have an installed Perl, which is as if not more heavy-weight dependency than cmake. You mentioned majority. Nope: a majority now provide a cmake option. Bottom line is that I and quite some fellows are sticking with the GUI/dsw/dsp/mak. Oh so easy in all aspects for me as non unix user. And cmake will give you DSW/DSP, or SLN/VcProj, or... So what is your complaint to perpetuate a legacy unsupported(*) commercial standard by the entire project when an open and cross platform alternative exists which is modifible and maintainable by all committers exists and is required ultimately to have a binary build at all? I encourage all to use what they are most comfortable with, whether is is DSW/DSP on Studio 6, or the most recent project format of Studio 2017, or plain old .mak files. As The Designer, the Windows build was crafted to require as few specific additional tools as possible, and if required, keep them small and easy to procure. Awk (vs Perl) is one example. When cmake wasn't needed by one of our dependencies in the past, requiring cmake seemed excessive. With the transition of PCRE and likely soon others, leveraging cmake becomes dirt simple obvious. We don't devolve here to proposal A sucks, B rules; we have reasoned technical discussions on the merits of proposal A vs B. I need your technical argument against adopting cmake before we can finish this reasoned argument.
Re: mod_brotli in 2.4.x is missing a few Makefile changes
cvtdsp.pl is not a hassle, just a easy step. Quote: you should not need cvtdsp.pl -2005 with VC14. They fixed this in the conversion. You mentioned majority. Nope: a majority now provide a cmake option. Bottom line is that I and quite some fellows are sticking with the GUI/dsw/dsp/mak. Oh so easy in all aspects for me as non unix user. > Op 28 apr. 2017 om 19:43 heeft William A Rowe Jrhet > volgende geschreven: > > It's not a question of majority - a majority now provide a cmake option. > > It is a question of dependency, PCRE must be built, PCRE must be > configured with cmake, cmake is a mandatory tool for configuring httpd > on windows, irrespective of how many times it must be invoked. brotli > is a new nice-to-have and offers three different build solutions. > > If invoked for httpd, the resulting *build* may be Microsoft Solution Files, > Microsoft MSBuild Files, Microsoft NMake files and even others. It can > emit .dsp files, not that anyone would want that today :) > > So arguing that utilizing cmake 'removes the studio files' misses the point. > They aren't lost, they are easily created without the hassles of cvtdsp.pl > and in a manner that can be maintained and tested by even the Unix-only > contributors. > > >> On Fri, Apr 28, 2017 at 12:11 PM, Steffen wrote: >> Accurate: I only/must use cmake with pcre and brotli, rest/most is make. >> No cmake *majority*. >> Op 28 apr. 2017 om 18:45 heeft William A Rowe Jr het volgende geschreven: On Fri, Apr 28, 2017 at 11:35 AM, Jan Ehrhardt wrote: William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03 -0500): > You might have missed my thought here... suggesting that the CMake > not-so-experimental build become recommended for users who want to > build all the modules in one go including the new mod_brotli. People like Steffen, Gregg and me disagree with you on making CMake the only way for building Apache and all the modules in one go. >>> >>> And until brotli (topic of current discussion) it was convenient to hide >>> behind >>> the fact that CMake wasn't necessary. Now that the *majority* of httpd >>> project >>> dependencies must all be configured using cmake (and build with one of a >>> number of actual toolchains, including your favored Visual Studio GUI view, >>> msbuild, nmake makefiles, even eclipse etc etc etc.) the most compelling >>> reason to ship .mak + .dsp has now evaporated. >>> >>> I will never invoke devenv.exe "target" from the CMake output, I like the >>> simpler forms better, but I'm happy to help diagnose anything that CMake >>> is doing wrong in emitting the vcproj or makefile output for your >>> consumption. >>> >>> The lack of understanding of why these libs exist in the .mak and not in the >>> .dep files Gregg updated illustrates that the old .dsp files are no longer >>> of >>> any substantive value. As I mentioned earlier, I haven't used the .dsw or >>> these resulting .mak files in a decade because my httpd.exe+++ build all >>> seeks an installed tree expat/pcre/apr/openssl/libxml2/zlib (ultimately, the >>> final install prefix for httpd), and I can fix everything by munging INCLUDE >>> and LIB envvars vs. a nightmare of unpacking sources into directories of >>> different names than their source distribution, keeping up with build tree >>> restructuring by the maintainers, or munging .dsp/.mak files. >>
Re: mod_brotli in 2.4.x is missing a few Makefile changes
It's not a question of majority - a majority now provide a cmake option. It is a question of dependency, PCRE must be built, PCRE must be configured with cmake, cmake is a mandatory tool for configuring httpd on windows, irrespective of how many times it must be invoked. brotli is a new nice-to-have and offers three different build solutions. If invoked for httpd, the resulting *build* may be Microsoft Solution Files, Microsoft MSBuild Files, Microsoft NMake files and even others. It can emit .dsp files, not that anyone would want that today :) So arguing that utilizing cmake 'removes the studio files' misses the point. They aren't lost, they are easily created without the hassles of cvtdsp.pl and in a manner that can be maintained and tested by even the Unix-only contributors. On Fri, Apr 28, 2017 at 12:11 PM, Steffenwrote: > Accurate: I only/must use cmake with pcre and brotli, rest/most is make. > No cmake *majority*. > >> Op 28 apr. 2017 om 18:45 heeft William A Rowe Jr het >> volgende geschreven: >> >>> On Fri, Apr 28, 2017 at 11:35 AM, Jan Ehrhardt wrote: >>> William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03 >>> -0500): You might have missed my thought here... suggesting that the CMake not-so-experimental build become recommended for users who want to build all the modules in one go including the new mod_brotli. >>> >>> People like Steffen, Gregg and me disagree with you on making CMake the >>> only way for building Apache and all the modules in one go. >> >> And until brotli (topic of current discussion) it was convenient to hide >> behind >> the fact that CMake wasn't necessary. Now that the *majority* of httpd >> project >> dependencies must all be configured using cmake (and build with one of a >> number of actual toolchains, including your favored Visual Studio GUI view, >> msbuild, nmake makefiles, even eclipse etc etc etc.) the most compelling >> reason to ship .mak + .dsp has now evaporated. >> >> I will never invoke devenv.exe "target" from the CMake output, I like the >> simpler forms better, but I'm happy to help diagnose anything that CMake >> is doing wrong in emitting the vcproj or makefile output for your >> consumption. >> >> The lack of understanding of why these libs exist in the .mak and not in the >> .dep files Gregg updated illustrates that the old .dsp files are no longer of >> any substantive value. As I mentioned earlier, I haven't used the .dsw or >> these resulting .mak files in a decade because my httpd.exe+++ build all >> seeks an installed tree expat/pcre/apr/openssl/libxml2/zlib (ultimately, the >> final install prefix for httpd), and I can fix everything by munging INCLUDE >> and LIB envvars vs. a nightmare of unpacking sources into directories of >> different names than their source distribution, keeping up with build tree >> restructuring by the maintainers, or munging .dsp/.mak files. >
Re: mod_brotli in 2.4.x is missing a few Makefile changes
Accurate: I only/must use cmake with pcre and brotli, rest/most is make. No cmake *majority*. > Op 28 apr. 2017 om 18:45 heeft William A Rowe Jrhet > volgende geschreven: > >> On Fri, Apr 28, 2017 at 11:35 AM, Jan Ehrhardt wrote: >> William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03 >> -0500): >>> You might have missed my thought here... suggesting that the CMake >>> not-so-experimental build become recommended for users who want to >>> build all the modules in one go including the new mod_brotli. >> >> People like Steffen, Gregg and me disagree with you on making CMake the >> only way for building Apache and all the modules in one go. > > And until brotli (topic of current discussion) it was convenient to hide > behind > the fact that CMake wasn't necessary. Now that the *majority* of httpd project > dependencies must all be configured using cmake (and build with one of a > number of actual toolchains, including your favored Visual Studio GUI view, > msbuild, nmake makefiles, even eclipse etc etc etc.) the most compelling > reason to ship .mak + .dsp has now evaporated. > > I will never invoke devenv.exe "target" from the CMake output, I like the > simpler forms better, but I'm happy to help diagnose anything that CMake > is doing wrong in emitting the vcproj or makefile output for your consumption. > > The lack of understanding of why these libs exist in the .mak and not in the > .dep files Gregg updated illustrates that the old .dsp files are no longer of > any substantive value. As I mentioned earlier, I haven't used the .dsw or > these resulting .mak files in a decade because my httpd.exe+++ build all > seeks an installed tree expat/pcre/apr/openssl/libxml2/zlib (ultimately, the > final install prefix for httpd), and I can fix everything by munging INCLUDE > and LIB envvars vs. a nightmare of unpacking sources into directories of > different names than their source distribution, keeping up with build tree > restructuring by the maintainers, or munging .dsp/.mak files.
Re: mod_brotli in 2.4.x is missing a few Makefile changes
On Fri, Apr 28, 2017 at 11:35 AM, Jan Ehrhardtwrote: > William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03 > -0500): >>You might have missed my thought here... suggesting that the CMake >>not-so-experimental build become recommended for users who want to >>build all the modules in one go including the new mod_brotli. > > People like Steffen, Gregg and me disagree with you on making CMake the > only way for building Apache and all the modules in one go. And until brotli (topic of current discussion) it was convenient to hide behind the fact that CMake wasn't necessary. Now that the *majority* of httpd project dependencies must all be configured using cmake (and build with one of a number of actual toolchains, including your favored Visual Studio GUI view, msbuild, nmake makefiles, even eclipse etc etc etc.) the most compelling reason to ship .mak + .dsp has now evaporated. I will never invoke devenv.exe "target" from the CMake output, I like the simpler forms better, but I'm happy to help diagnose anything that CMake is doing wrong in emitting the vcproj or makefile output for your consumption. The lack of understanding of why these libs exist in the .mak and not in the .dep files Gregg updated illustrates that the old .dsp files are no longer of any substantive value. As I mentioned earlier, I haven't used the .dsw or these resulting .mak files in a decade because my httpd.exe+++ build all seeks an installed tree expat/pcre/apr/openssl/libxml2/zlib (ultimately, the final install prefix for httpd), and I can fix everything by munging INCLUDE and LIB envvars vs. a nightmare of unpacking sources into directories of different names than their source distribution, keeping up with build tree restructuring by the maintainers, or munging .dsp/.mak files.
Re: mod_brotli in 2.4.x is missing a few Makefile changes
William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03 -0500): >You might have missed my thought here... suggesting that the CMake >not-so-experimental build become recommended for users who want to >build all the modules in one go including the new mod_brotli. People like Steffen, Gregg and me disagree with you on making CMake the only way for building Apache and all the modules in one go. >It sounds like you attempted to export mod_brotli.dsp to a vcproj all >on it's own which has never been possible. It is perfectly possible. That is how I added mod_fcgid and now mod_brotli to my existing Apache 2.4.25 sln. Convert to vcproj (VC9) or vcxproj (VC11/VC14), add the x64 configuration, add the vc(x)proj as an existing project to Apache.sln. I am doing the same thing when mod_http2 changes the headers or sources. For 2.4.next I will convert Apache.dsw once again and add mod_fcgid afterwards. -- Jan
Re: mod_brotli in 2.4.x is missing a few Makefile changes
On 04/28/2017 08:08 AM, Steffen wrote: Cmake is a way to go. IDE building is the preferred way to go, all the vs goodies then available. And easy to maintain dsw and dsp etc. Does CMake not provide the nice IDE goodies on your machine? I'm quite happy with it for mod_websocket, and not at all happy with the dsw/dsp, which I've never gotten to upconvert correctly to the latest VS version. --Jacob
Re: mod_brotli in 2.4.x is missing a few Makefile changes
On Fri, Apr 28, 2017 at 10:05 AM, Jan Ehrhardtwrote: > William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 09:57:53 > -0500): >>Hmmm... >> >>Building brotli libs requires CMake. >> >>Perhaps only support building mod_brotli through the CMake build, and not >>the legacy build? > > That would be not very convenient if you want to build Apache with all > modules in one go. You might have missed my thought here... suggesting that the CMake not-so-experimental build become recommended for users who want to build all the modules in one go including the new mod_brotli. It sounds like you attempted to export mod_brotli.dsp to a vcproj all on it's own which has never been possible. If you loaded Apache[2].dsw and allowed it convert *all* the modules, mod_brotli.dsp should be fine.
Re: mod_brotli in 2.4.x is missing a few Makefile changes
Agree. Thanks to Gregg, dsp/dsw/makefile mod_brotli is already there in branches 2.4.x. Cmake only needed to build the brotli libs. > Op 28 apr. 2017 om 17:05 heeft Jan Ehrhardthet volgende > geschreven: > > William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 09:57:53 > -0500): >> Hmmm... >> >> Building brotli libs requires CMake. >> >> Perhaps only support building mod_brotli through the CMake build, and not >> the legacy build? > > That would be not very convenient if you want to build Apache with all > modules in one go. > -- > Jan >
Re: mod_brotli in 2.4.x is missing a few Makefile changes
This is a trigger again for the old repeating discussion. Cmake is a way to go. IDE building is the preferred way to go, all the vs goodies then available. And easy to maintain dsw and dsp etc. > Op 28 apr. 2017 om 16:55 heeft William A Rowe Jrhet > volgende geschreven: > > Jan, > > That is correct. The .dsp is wired to interrelated projects via the .dsw > file. Exporting the projects into .mak files causes all the 'depends upon' > libs to be added. See any other such as mod_status. If we were building > brotli in-tree you would add the libbrotli .dsp and it would resolve that lib. > > Which is why my product build (not /dist/httpd/ win32 binary) differed for a > decade+... My clone of Apache.dsw has no apr, therefore I used the cvtdsp.pl > logic to put in all the required libapr-1.lib dependencies. A real PITA. > > They simply go away after httpd-2.4.x as no longer supported. CMake just > works and eliminates a ton of ASF and external maintenance. > > > >> On Apr 28, 2017 9:19 AM, "Jan Ehrhardt" wrote: >> Hi Gregg, >> >> Gregg Smith in gmane.comp.apache.devel (Tue, 25 Apr 2017 18:23:50 >> -0700): >> >Actually, I'll test here in a while and commit tomorrow. >> >> Quote from modules/filters/mod_brotli.dsp >> >> > +# ADD LINK32 kernel32.lib brotlicommon.lib brotlienc.lib /nologo >> > /subsystem:windows /dll /incremental:no /debug >> > /out:".\Release\mod_brotli.so" /libpath:"../../srclib/brotli" >> > /base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref >> >> The dsp seems to be missing a reference to libapr-1.lib, >> libaprutil-1.lib and libhttpd.lib, which is present in the >> mod_brotli.mak: >> >> +LINK32=link.exe >> +LINK32_FLAGS=kernel32.lib brotlicommon.lib brotlienc.lib /nologo >> /subsystem:windows /dll /incremental:no /pdb:"$(OUTDIR)\mod_brotli.pdb" >> /libpath="../../srclib/brotli" /debug /out:"$(OUTDIR)\mod_brotli.so" >> /implib:"$(OUTDIR)\mod_brotli.lib" >> /base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref >> +LINK32_OBJS= \ >> + "$(INTDIR)\mod_brotli.obj" \ >> + "$(INTDIR)\mod_brotli.res" \ >> + "..\..\srclib\apr\Release\libapr-1.lib" \ >> + "..\..\srclib\apr-util\Release\libaprutil-1.lib" \ >> + "..\..\Release\libhttpd.lib" >> >> When I converted the dsp to mod_brotli.vcxproj it did not compile >> because of missing symbols like __imp__apr_bucket* or something like >> that.. >> -- >> Jan >>
Re: mod_brotli in 2.4.x is missing a few Makefile changes
William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 09:57:53 -0500): >Hmmm... > >Building brotli libs requires CMake. > >Perhaps only support building mod_brotli through the CMake build, and not >the legacy build? That would be not very convenient if you want to build Apache with all modules in one go. -- Jan
Re: mod_brotli in 2.4.x is missing a few Makefile changes
OK, thx for clearing that up. Cheers! > On Apr 28, 2017, at 9:50 AM, Jan Ehrhardtwrote: > > Jim Jagielski in gmane.comp.apache.devel (Fri, 28 Apr 2017 09:29:01 > -0400): >> Are these issues with *building* the brotli library during >> the configure/make of httpd? > > No, building the brotli library itself is a CMake thing. Something like > > CMake -G "Visual Studio 14 2015 Win64" -DBUILD_SHARED_LIBS=OFF . > msbuild brotli.sln /P:Configuration=MinSizeRel > >> Why, exactly, are we doing this if this is, in fact, what >> we are doing? Just curious why we are taking this dependency >> on directly. > > The dependency on libapr-1.lib, libaprutil-1.lib and libhttpd.lib > (besides brotlicommon.lib and brotlienc.lib) is when building > mod_brotli.so. > -- > Jan >
Re: mod_brotli in 2.4.x is missing a few Makefile changes
Hmmm... Building brotli libs requires CMake. Perhaps only support building mod_brotli through the CMake build, and not the legacy build?
Re: mod_brotli in 2.4.x is missing a few Makefile changes
Jan, That is correct. The .dsp is wired to interrelated projects via the .dsw file. Exporting the projects into .mak files causes all the 'depends upon' libs to be added. See any other such as mod_status. If we were building brotli in-tree you would add the libbrotli .dsp and it would resolve that lib. Which is why my product build (not /dist/httpd/ win32 binary) differed for a decade+... My clone of Apache.dsw has no apr, therefore I used the cvtdsp.pl logic to put in all the required libapr-1.lib dependencies. A real PITA. They simply go away after httpd-2.4.x as no longer supported. CMake just works and eliminates a ton of ASF and external maintenance. On Apr 28, 2017 9:19 AM, "Jan Ehrhardt"wrote: > Hi Gregg, > > Gregg Smith in gmane.comp.apache.devel (Tue, 25 Apr 2017 18:23:50 > -0700): > >Actually, I'll test here in a while and commit tomorrow. > > Quote from modules/filters/mod_brotli.dsp > > > +# ADD LINK32 kernel32.lib brotlicommon.lib brotlienc.lib /nologo > /subsystem:windows /dll /incremental:no /debug > /out:".\Release\mod_brotli.so" /libpath:"../../srclib/brotli" /base:@ > ..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref > > The dsp seems to be missing a reference to libapr-1.lib, > libaprutil-1.lib and libhttpd.lib, which is present in the > mod_brotli.mak: > > +LINK32=link.exe > +LINK32_FLAGS=kernel32.lib brotlicommon.lib brotlienc.lib /nologo > /subsystem:windows /dll /incremental:no /pdb:"$(OUTDIR)\mod_brotli.pdb" > /libpath="../../srclib/brotli" /debug /out:"$(OUTDIR)\mod_brotli.so" > /implib:"$(OUTDIR)\mod_brotli.lib" > /base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref > +LINK32_OBJS= \ > + "$(INTDIR)\mod_brotli.obj" \ > + "$(INTDIR)\mod_brotli.res" \ > + "..\..\srclib\apr\Release\libapr-1.lib" \ > + "..\..\srclib\apr-util\Release\libaprutil-1.lib" \ > + "..\..\Release\libhttpd.lib" > > When I converted the dsp to mod_brotli.vcxproj it did not compile > because of missing symbols like __imp__apr_bucket* or something like > that.. > -- > Jan > >
Re: mod_brotli in 2.4.x is missing a few Makefile changes
Jim Jagielski in gmane.comp.apache.devel (Fri, 28 Apr 2017 09:29:01 -0400): >Are these issues with *building* the brotli library during >the configure/make of httpd? No, building the brotli library itself is a CMake thing. Something like CMake -G "Visual Studio 14 2015 Win64" -DBUILD_SHARED_LIBS=OFF . msbuild brotli.sln /P:Configuration=MinSizeRel >Why, exactly, are we doing this if this is, in fact, what >we are doing? Just curious why we are taking this dependency >on directly. The dependency on libapr-1.lib, libaprutil-1.lib and libhttpd.lib (besides brotlicommon.lib and brotlienc.lib) is when building mod_brotli.so. -- Jan
Re: mod_brotli in 2.4.x is missing a few Makefile changes
This just clicked for me... Are these issues with *building* the brotli library during the configure/make of httpd? Why, exactly, are we doing this if this is, in fact, what we are doing? Just curious why we are taking this dependency on directly. > On Apr 28, 2017, at 9:19 AM, Jan Ehrhardtwrote: > > Hi Gregg, > > Gregg Smith in gmane.comp.apache.devel (Tue, 25 Apr 2017 18:23:50 > -0700): >> Actually, I'll test here in a while and commit tomorrow. > > Quote from modules/filters/mod_brotli.dsp > >> +# ADD LINK32 kernel32.lib brotlicommon.lib brotlienc.lib /nologo >> /subsystem:windows /dll /incremental:no /debug >> /out:".\Release\mod_brotli.so" /libpath:"../../srclib/brotli" >> /base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref > > The dsp seems to be missing a reference to libapr-1.lib, > libaprutil-1.lib and libhttpd.lib, which is present in the > mod_brotli.mak: > > +LINK32=link.exe > +LINK32_FLAGS=kernel32.lib brotlicommon.lib brotlienc.lib /nologo > /subsystem:windows /dll /incremental:no /pdb:"$(OUTDIR)\mod_brotli.pdb" > /libpath="../../srclib/brotli" /debug /out:"$(OUTDIR)\mod_brotli.so" > /implib:"$(OUTDIR)\mod_brotli.lib" > /base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref > +LINK32_OBJS= \ > + "$(INTDIR)\mod_brotli.obj" \ > + "$(INTDIR)\mod_brotli.res" \ > + "..\..\srclib\apr\Release\libapr-1.lib" \ > + "..\..\srclib\apr-util\Release\libaprutil-1.lib" \ > + "..\..\Release\libhttpd.lib" > > When I converted the dsp to mod_brotli.vcxproj it did not compile > because of missing symbols like __imp__apr_bucket* or something like > that.. > -- > Jan >
Re: mod_brotli in 2.4.x is missing a few Makefile changes
Hi Gregg, Gregg Smith in gmane.comp.apache.devel (Tue, 25 Apr 2017 18:23:50 -0700): >Actually, I'll test here in a while and commit tomorrow. Quote from modules/filters/mod_brotli.dsp > +# ADD LINK32 kernel32.lib brotlicommon.lib brotlienc.lib /nologo > /subsystem:windows /dll /incremental:no /debug /out:".\Release\mod_brotli.so" > /libpath:"../../srclib/brotli" > /base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref The dsp seems to be missing a reference to libapr-1.lib, libaprutil-1.lib and libhttpd.lib, which is present in the mod_brotli.mak: +LINK32=link.exe +LINK32_FLAGS=kernel32.lib brotlicommon.lib brotlienc.lib /nologo /subsystem:windows /dll /incremental:no /pdb:"$(OUTDIR)\mod_brotli.pdb" /libpath="../../srclib/brotli" /debug /out:"$(OUTDIR)\mod_brotli.so" /implib:"$(OUTDIR)\mod_brotli.lib" /base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref +LINK32_OBJS= \ + "$(INTDIR)\mod_brotli.obj" \ + "$(INTDIR)\mod_brotli.res" \ + "..\..\srclib\apr\Release\libapr-1.lib" \ + "..\..\srclib\apr-util\Release\libaprutil-1.lib" \ + "..\..\Release\libhttpd.lib" When I converted the dsp to mod_brotli.vcxproj it did not compile because of missing symbols like __imp__apr_bucket* or something like that.. -- Jan
Re: mod_brotli in 2.4.x is missing a few Makefile changes
Jim Jagielskiwrites: > BTW, there are also deltas for config.m4 in modules/filters mainly > around mod_brotli. At present what is in 2.4 seems to work fine, but > should we consider backporting config.m4 as well? The difference is caused by these four mentioned changes (r1761824, r1771789, r1771827, r1779111). With them applied, this part of the modules/filters/config.m4 file should be identical between trunk and 2.4.x. I proposed the whole group for the backport in r1792805 and r1792806. Regards, Evgeny Kotkov
Re: mod_brotli in 2.4.x is missing a few Makefile changes
On 4/26/2017 7:53 AM, Jim Jagielski wrote: Thanks! Are these the full diffs for Makefile? On Apr 26, 2017, at 10:50 AM, Gregg Smithwrote: On 4/26/2017 4:51 AM, Jim Jagielski wrote: On Apr 25, 2017, at 4:34 PM, Evgeny Kotkov wrote: Hi all, I noticed that the version of mod_brotli that has been backported to 2.4.x lacks a few Makefile changes from trunk. This results in a failing Unix build when mod_brotli is not being built. Hmmm I can't recreate that here on CentOS or macOS. Nevertheless, I know that the Makefiles were diff, but the backport didn't include those diffs so I couldn't just apply them after the fact, so I am +1 for adding them as a "new" backport. Tested both IDE and command line builds. Commited r1792753 Yes, for the legacy build. Includes the addition to BaseAddr.ref (which conflicts from trunk due to the different order in which modules have been added to 2.4). Addition to the LoadModule section of the Windows httpd.conf. We should be good to go all the way around.
Re: mod_brotli in 2.4.x is missing a few Makefile changes
BTW, there are also deltas for config.m4 in modules/filters mainly around mod_brotli. At present what is in 2.4 seems to work fine, but should we consider backporting config.m4 as well?
Re: mod_brotli in 2.4.x is missing a few Makefile changes
Thanks! Are these the full diffs for Makefile? > On Apr 26, 2017, at 10:50 AM, Gregg Smithwrote: > > > On 4/26/2017 4:51 AM, Jim Jagielski wrote: >> >>> On Apr 25, 2017, at 4:34 PM, Evgeny Kotkov >>> wrote: >>> >>> Hi all, >>> >>> I noticed that the version of mod_brotli that has been backported to 2.4.x >>> lacks a few Makefile changes from trunk. This results in a failing Unix >>> build when mod_brotli is not being built. >> >> Hmmm I can't recreate that here on CentOS or macOS. >> >> Nevertheless, I know that the Makefiles were diff, but the >> backport didn't include those diffs so I couldn't just apply >> them after the fact, so I am +1 for adding them as a "new" >> backport. >> > Tested both IDE and command line builds. > Commited r1792753
Re: mod_brotli in 2.4.x is missing a few Makefile changes
On 4/26/2017 4:51 AM, Jim Jagielski wrote: On Apr 25, 2017, at 4:34 PM, Evgeny Kotkovwrote: Hi all, I noticed that the version of mod_brotli that has been backported to 2.4.x lacks a few Makefile changes from trunk. This results in a failing Unix build when mod_brotli is not being built. Hmmm I can't recreate that here on CentOS or macOS. Nevertheless, I know that the Makefiles were diff, but the backport didn't include those diffs so I couldn't just apply them after the fact, so I am +1 for adding them as a "new" backport. Tested both IDE and command line builds. Commited r1792753
Re: mod_brotli in 2.4.x is missing a few Makefile changes
> On Apr 25, 2017, at 4:34 PM, Evgeny Kotkov> wrote: > > Hi all, > > I noticed that the version of mod_brotli that has been backported to 2.4.x > lacks a few Makefile changes from trunk. This results in a failing Unix > build when mod_brotli is not being built. Hmmm I can't recreate that here on CentOS or macOS. Nevertheless, I know that the Makefiles were diff, but the backport didn't include those diffs so I couldn't just apply them after the fact, so I am +1 for adding them as a "new" backport.
Re: mod_brotli in 2.4.x is missing a few Makefile changes
Actually, I'll test here in a while and commit tomorrow. On 4/25/2017 6:20 PM, Gregg Smith wrote: I have one, command line makefiles and all. I just haven't had time to run a test build yet though lloking at it looks fine, but I like to test first. On 4/25/2017 2:07 PM, Yann Ylavic wrote: Hi Evgeny, On Tue, Apr 25, 2017 at 10:34 PM, Evgeny Kotkovwrote: With the backport being in place in the 2.4.x branch, these changes no longer merge cleanly from trunk. I can prepare a backport nomination for them that resolves the conflicts and add it to the 2.4.x STATUS. What do you think? +1 Regards, Yann. Index: Apache-apr2.dsw === --- Apache-apr2.dsw (revision 1792168) +++ Apache-apr2.dsw (working copy) @@ -1243,6 +1243,24 @@ ### +Project: "mod_brotli"=.\modules\filters\mod_brotli.dsp - Package Owner=<4> + +Package=<5> +{{{ +}}} + +Package=<4> +{{{ +Begin Project Dependency +Project_Dep_Name libapr +End Project Dependency +Begin Project Dependency +Project_Dep_Name libhttpd +End Project Dependency +}}} + +### + Project: "mod_bucketeer"=.\modules\debugging\mod_bucketeer.dsp - Package Owner=<4> Package=<5> Index: Apache.dsw === --- Apache.dsw (revision 1792168) +++ Apache.dsw (working copy) @@ -1483,6 +1483,27 @@ ### +Project: "mod_brotli"=.\modules\filters\mod_brotli.dsp - Package Owner=<4> + +Package=<5> +{{{ +}}} + +Package=<4> +{{{ +Begin Project Dependency +Project_Dep_Name libapr +End Project Dependency +Begin Project Dependency +Project_Dep_Name libaprutil +End Project Dependency +Begin Project Dependency +Project_Dep_Name libhttpd +End Project Dependency +}}} + +### + Project: "mod_bucketeer"=.\modules\debugging\mod_bucketeer.dsp - Package Owner=<4> Package=<5> Index: build/installwinconf.awk === --- build/installwinconf.awk (revision 1792168) +++ build/installwinconf.awk (working copy) @@ -116,6 +116,7 @@ print "#LoadModule authz_owner_module modules/mod_authz_owner.so" > dstfl; print "LoadModule authz_user_module modules/mod_authz_user.so" > dstfl; print "LoadModule autoindex_module modules/mod_autoindex.so" > dstfl; + print "#LoadModule brotli_module modules/mod_brotli.so" > dstfl; print "#LoadModule buffer_module modules/mod_buffer.so" > dstfl; print "#LoadModule cache_module modules/mod_cache.so" > dstfl; print "#LoadModule cache_disk_module modules/mod_cache_disk.so" > dstfl; Index: BuildBin.dsp === --- BuildBin.dsp (revision 1792168) +++ BuildBin.dsp (working copy) @@ -39,7 +39,7 @@ # PROP Use_Debug_Libraries 0 # PROP Output_Dir "" # PROP Intermediate_Dir "" -# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache2" LONG=Release _trydb _trylua _tryxml _tryssl _tryzlib _trynghttp2 _dummy" +# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache2" LONG=Release _trydb _trylua _tryxml _tryssl _tryzlib _trynghttp2 _trybrotli _dummy" # PROP Rebuild_Opt "" # PROP Target_File "\Apache2\bin\httpd.exe" # PROP Bsc_Name ".\Browse\httpd.bsc" @@ -58,7 +58,7 @@ # PROP Use_Debug_Libraries 1 # PROP Output_Dir "" # PROP Intermediate_Dir "" -# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache2" LONG=Debug _trydb _trylua _tryxml _tryssl _tryzlib _trynghttp2 _dummy" +# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache2" LONG=Debug _trydb _trylua _tryxml _tryssl _tryzlib _trynghttp2 _trybrotli _dummy" # PROP Rebuild_Opt "" # PROP Target_File "\Apache2\bin\httpd.exe" # PROP Bsc_Name ".\Browse\httpd.bsc" Index: Makefile.win === --- Makefile.win (revision 1792168) +++ Makefile.win (working copy) @@ -268,6 +268,33 @@ !ENDIF +!IF EXIST("srclib\brotli") + +_trybrotli: +!IF $(USEMAK) == 1 + cd modules\filters + $(MAKE) $(MAKEOPT) -f mod_brotli.mak CFG="mod_brotli - Win32 $(LONG)" RECURSE=0 $(CTARGET) + cd ..\.. +!ELSEIF $(USESLN) == 1 + devenv $(TLP).sln /useenv $(CTARGET) $(LONG) /project mod_brotli +!ELSE + @msdev $(TLP).dsw /USEENV /MAKE \ + "mod_brotli - Win32 $(LONG)" /NORECURSE $(CTARGET) +!ENDIF + +!ELSE +# NOT EXIST("srclib\brotli") + +_trybrotli: + @echo - + @echo mod_brotli will not build unless brotli is built in srclib\brotli. + @echo Version 1.0.0 and later available from https://github.com/google/brotli/releases + @echo build with: + @echo cmake -G "NMake Makefiles"
Re: mod_brotli in 2.4.x is missing a few Makefile changes
I have one, command line makefiles and all. I just haven't had time to run a test build yet though lloking at it looks fine, but I like to test first. On 4/25/2017 2:07 PM, Yann Ylavic wrote: Hi Evgeny, On Tue, Apr 25, 2017 at 10:34 PM, Evgeny Kotkovwrote: With the backport being in place in the 2.4.x branch, these changes no longer merge cleanly from trunk. I can prepare a backport nomination for them that resolves the conflicts and add it to the 2.4.x STATUS. What do you think? +1 Regards, Yann.
Re: mod_brotli in 2.4.x is missing a few Makefile changes
Hi Evgeny, On Tue, Apr 25, 2017 at 10:34 PM, Evgeny Kotkovwrote: > > With the backport being in place in the 2.4.x branch, these changes no longer > merge cleanly from trunk. I can prepare a backport nomination for them that > resolves the conflicts and add it to the 2.4.x STATUS. > > What do you think? +1 Regards, Yann.
mod_brotli in 2.4.x is missing a few Makefile changes
Hi all, I noticed that the version of mod_brotli that has been backported to 2.4.x lacks a few Makefile changes from trunk. This results in a failing Unix build when mod_brotli is not being built. Another issue is that by default the CMakeLists.txt file refers to invalid library filenames. ./configure ; make ... Building shared: mod_buffer.la mod_ratelimit.la mod_reqtimeout.la mod_ext_filter.la mod_request.la mod_include.la mod_filter.la mod_substitute.la mod_sed.la mod_deflate.la /usr/bin/ld: cannot find -lbrotlienc collect2: error: ld returned 1 exit status ... The missing changesets are: https://svn.apache.org/r1761824 https://svn.apache.org/r1771789 https://svn.apache.org/r1771827 https://svn.apache.org/r1779111 Here is the shortlog for them: r1761824: Unbreak building other filter modules without libbrotlienc. r1771789: Rewrite the autoconf script in a, hopefully, less convoluted way. This lays the groundwork to simplify the switch to the official Brotli library. r1771827: Update makefiles to use the library layout of the official Brotli repository. r1779111: Update makefile to cope with the pkg-config layout change in https://github.com/google/brotli/commit/fe9f9a9 With the backport being in place in the 2.4.x branch, these changes no longer merge cleanly from trunk. I can prepare a backport nomination for them that resolves the conflicts and add it to the 2.4.x STATUS. What do you think? Regards, Evgeny Kotkov