I second what you are saying about modern CMake. When I first switched to CMake years ago I grew to regret it. It worked but it was a total mess. Then a couple

I second what you are saying about modern CMake. When I first switched to CMake years ago I grew to regret it. It worked but it was a total mess. Then a couple years ago I saw someone mention "modern CMake" and I googled around and realized they had implemented a much more sane approach since I first learned it. There is more to it than just this but a lot of the time you can just do a few find_package(library) commands, an add_executable(program [source files]), and finally a target_link_libraries(program [libraries]) to declare your dependencies and everything just works. Include paths are correct. Private dependencies aren't cluttering up stuff downstream. Debug and release version of libraries work as expected. Build flags and compiler definitions only apply to the modules you intended them to apply to. This is why I've been liking the approach Microsoft has been taking with vcpkg. They clearly see which way the wind is blowing. It's not restricted to using CMake but there is a strong preference for it and it uses CMake as its build scripting system. I just barely got done trying it on a large project for dependencies and it worked very well overall. A few commands to install a dozen or so dependencies and a quick change to add the vcpkg CMake toolchain so Visual Studio will pass it to CMake. After that and I can just use Open Folder on my CMake project in Visual Studio 2017 and everything just works. It's still a little rough around the edges but vcpkg seems to be developing at a breakneck speed for how new it is. Dealing with dependencies is the worst part about being a C++ Developer and I'm glad to finally have something that makes it this easy (on one platform at least; I still get to rip my hair out on macOS).