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
and in a manner that can be maintained and tested by even the Unix-only

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.

Reply via email to