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 Jr <wr...@rowe-clan.net> het > 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 <i...@apachelounge.com> 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 <wr...@rowe-clan.net> het >>>> volgende geschreven: >>>> >>>> On Fri, Apr 28, 2017 at 11:35 AM, Jan Ehrhardt <php...@ehrhardt.nl> 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. >>
