Ooh, this caught my eye. Mild apologies for poking my head in.

On 12/20/2016 10:48 PM, Ivan Zhakov wrote:
The problem with generators like CMake that they multiply problems in
MSVC + SDK.

Can you expand on this? I'm quite happy with CMake + APR 2.0 + httpd on Windows for my test builds.

I personally still prefer using native build tools, like APR *already*
uses for other platforms: autoconf/configure for *nix, NWGNUMake for
Netware. The only benefit would be if CMake will be possible for *all*
platforms, for *nix feel CMake pain too :) In this case benefit would
to have single place for included source files etc.

This position confuses me a bit. I thought the entire point of CMake was to generate a native build system, no? And you can choose *which* build system to generate based on the tools you have available to you, which is awesome.

I understand CMake has bugs, and I agree that those bugs have to be weighed against the benefit of using "yet another" tool. But the job of the CMake developers is to find and fix those bugs, while the job of APR developers should be to find and fix bugs in APR (as opposed to fixing bugs in yet another handcrafted build system).

CMake pollutes working copy with some unrelated files.

...it does? I don't think I've had any pollution with my workflow, since CMake gives you the option to separate the build tree from the source tree. What files do you see showing up?

Generated solution/project files are not perfect and to tweak them developer 
have to deal with CMake.

Agreed. But three years down the road, after the expert who hand-crafted a custom .mak solution has moved on to better things and we're on Visual Studio vNext, I'm guessing you'll find the same thing will happen there too -- unless you have a plan in mind to avoid it?

--Jacob

Reply via email to