|
|
|
|
|
|
by jcelerier
769 days ago
|
|
|
I mean, you say "Linux distributions can do it" but obviously you cannot use distro packages for any serious deployment where your users expect your app to look and feel exactly the same whether they're on Ubuntu or Fedora or Arch (or macOS or Windows). Or if you have patches, e.g. I have a couple patches to Qt. > Use `FetchContent_Declare` with `SOURCE_DIR` I know about this but it doesn't solve my problem: I want people who develop to be able to point to the source dir elsewhere, but I want e.g. CI and people who just grab it from github to have it point to some commit in usual FetchContent fashion. And I don't want to have to pass CMake flags for each "co-developed" dependency, that would be a very bad developer experience too. Every cmake flag I add is another couple support tickets from junior developers mistyping it in my experience. > a network drive that all developer terminals can access straightforwardly Not viable for OSS projects developed in the wild |
|
|
Then set up your CMake logic to use FetchContent_Declare based on the boolean value of an option, set up CMake presets[1] with hard-coded values for each CMake command-line option, and ask your developers/set CI to choose between these presets.
You mentioned a precompiled SDK; you can still use vcpkg and overlay ports to redirect to these prebuilt binaries[2]. Replace 'system package manager' with your own paths.
Or, forgo vcpkg altogether if you think the long initial bring-up is a big problem, and just use CMake and your pre-compiled SDK to expose packages, libraries, and headers that your consuming source needs. Not everything is a vcpkg-shaped nail that needs a vcpkg hammer.
[1]: https://cmake.org/cmake/help/latest/manual/cmake-presets.7.h...
[2]: https://devblogs.microsoft.com/cppblog/using-system-package-...