In addition, "modern CMake" is much better than classic CMake" and the project is improving with such things like CMake server.
I've been writing a simple video game in C++ recently, using CMake to build. I wrote a little bit of code that fetches the few libraries I need in order to have a complete/deterministic build process that works on linux/windows/mac. It lets me change versions (by specifying a new url to a source tarball). Versioned dependency management is so typical and convenient in many other languages and is such a pain in the butt with C++ because CMake is this thing that's sort of good enough. But my CMake experience doesn't compare well at all with maven, pip, gem, cargo, or even npm.
e: does anyone know if this has any relation to Boost's b2? I know that was originally based off of jam which is not related but the name is so similar I can't help but think I'm missing something :(
I like Ruby more than Python as a language, but I will say that I've never had pip fail to install a dependency on me.
I'm surprised there isn't any part of the gem process that calls `pkg-config`, to verify if a gem will be able to install, given its native dependencies. Having `bundle install` bail out after just a second with "please install libfoo first" would be great, especially for CI.
> I've never had pip fail to install a dependency on me
`pip install` has never failed me, but `pip install --upgrade` fails for me quite a bit. Especially when I try to use it like `gem upgrade`, with a stanza like
pip list --outdated --format=legacy | cut -d' ' -f1 | xargs pip install --upgradehttps://www.cvedetails.com/vulnerability-list/vendor_id-1749...
Too many C++ tools couple package management and build which increases their adoption cost and makes it more work to package third part packages. Conan takes the approach of managing dependencies and then giving your build system of choice the information it needs to access those dependencies via conan plugins. I think I had read that the author of Conan was involved in biicode and that the third party packaging problem is what inspired him to create Conan.
Some other cool things about conan
- Can be used for more than C++
- SCM independent
- Artifact caching
- Options allow clients to customize your package (creates distinct artifact)
- Scopes allow developers to modify your build (like conditional build steps so doesn't create a distinct artifact)
Some things I think can be improved
- Needs to separate out dependency lock file like Cargo or Poet
- Build tools need to be packaged in Conan for tracability / reproducibility
- Plugins are in Python which is heavy for deployment and has a large compatibility surface
- Easy to hit limits of declarative dependency files, being forced into implementing them in Python (see above)
- Project templates are hard coded.
No need to force me to install Python just to run a build tool.
Many of us only install what we actually need, or what the IT department allows on our images.
I certainly don't want to open a IT ticket to get Python, just to be able to compile random package X.
Conan does this too. If I follow the instructions to integrate cmake with conan, I would write something like this:
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup(TARGETS)
add_executable(timer timer.cpp)
target_link_libraries(timer CONAN_PKG::Poco)
Package managers like cget[1] or conda[2] does not couple the build with the package manager. Cget is also serverless which is nice as it can install dependencies from anywhere(even directly from github with `cget install jgm/cmark`), however, you need to setup your own server hosting if you want to install binaries.
http://docs.conan.io/en/latest/integrations/cmake/find_packa...
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).
Setting this up was a couple weeks of learning curve but I agree it is worth it to invest in Cmake and also learn the low-level details about how it all fits together since after all we are dealing with a native low-level language, it also pays to see under the hood of these "package managers" and build systems so you can be fluid on any platform where you need to build.
Here is someone who did something similar:
https://crascit.com/2015/07/25/cmake-gtest/
If you're interested I can upload my version a bit later
You can say do things like
"link to these header and this library" - and the modern-er syntax makes that cleaner
but you still can't do a simple
"Get this dependency, build it, then link my current project to it"
To me this is a very strange and frustrating limitation b/c all the necessary piece are already there! It just doesn't have the functionality to call "build it" in the middle like that for some reason. I actually ended up hacking it in (it's like 50 lines of code) but it's a bit ugly and doesn't work recursively
EDIT: It's also very inconvenient to do out-of-source builds with dependencies... constant source of frustration
[0] http://thetoeb.de/2016/08/30/modern-cmake-presentation/
[1] https://www.slideshare.net/DanielPfeifer1/cmake-48475415
And this blog post also has some good stuff: