3 ms·
I feel that if the author took the time to learn the problem domain well and why conan & vcpkg happen to exist, then this article wouldn't have been written. It
by halayli 5y ago
I feel that if the author took the time to learn the problem domain well and why conan & vcpkg happen to exist, then this article wouldn't have been written. It's not like people that started conan/vcpkg didn't know about cmake's FetchContent and friends.
Just a simple case of switching branches where some dependencies are different is going to trigger a lot of issues. And it's a big waste of time waiting for everything to compile instead of having a package server like jfrog hosting compiled libraries & source and making sure all your flags and toolchain setup is applied. And dealing with library versions, and making them available to other dependencies outside your project. And having projects that use cmake and others that use autotools, and some that are custom etc. Those issues are a few obvious ones that you'll see if you barely scratch the surface.
Unfortunately, this article will stay on the internet and spread a very problematic way of dealing with dependencies.
- rualca 5y ago> I feel that if the author took the time to learn the problem domain well and why conan & vcpkg happen to exist, then this article wouldn't have been written. It's not like people that started conan/vcpkg didn't know about cmake's FetchContent and friends. Exactly this. I would add that the author, for some reason, left out the most basic and I dare standard way to manage third-party dependencies: have a setup/provision script that downloads and installs dependencies locally. You know, what Conan does, but ad-hoc. In Linux it might be just a call to the package manager to install stuff from a djstro's dependencies, a kin to NPM's npm install. In Windows it might even be a big whole zip file bundling prebuilt binaries.