[jcelerier]

Every time I try to fully migrate from submodules I hit the following roadblocks:

- vcpkg: dependencies that have custom patches only relevant for my software or where maintainers apply patches once every six months, dependencies where the author doesn't do versioning and the correct version to use is git HEAD

- vcpkg: not sure how I can pass specific flags to dependencies. For instance I need to build LLVM with specific CMake flags.

- CMake FetchContent : how do you handle dependencies that are other repos from your organization which may definitely get patches as part of the development of the software? With FetchContent all those go into build directories and aren't treated as source, I would like to be able to tell CMake "for this build, use source folder /foo for dependency "foo" instead of cloning its 300MB repo again

- How do you handle dependencies that takes ages to build. My software uses Qt, llvm, libclang, ffmpeg and a fair amount of other things. When I tried with vcpkg, the experience building for a new contributor took something like three hours on an average laptop and required dozens of gigabytes of space (software build itself is ~5 minutes with the current precompiled SDK I ship). The space thing is critical, I often get students, interns, OSS contributors etc which definitely cannot afford 30GB of free space on cheap laptops with 256G SSDs

[tkuraku]

Cmake + submodules seems to be the most reliable option. I always hit issues with vcpkg.

[delta_p_delta_x]

> - vcpkg: dependencies that have custom patches only relevant for my software or where maintainers apply patches once every six months

Yeah, this is a pain point; maintainers need to be more on-the-ball about updating and maintaining packages and package versioning. Maintainers for large Linux package repos (e.g. apt, yum, pacman) can do it, I don't see why vcpkg maintainers can't.

> vcpkg: not sure how I can pass specific flags to dependencies. For instance I need to build LLVM with specific CMake flags.

Use overlay ports[1] and edit the portfile.cmake to pass in additional variables[2]. If you want this to be really configurable every time, then use `VCPKG_ENV_PASSTHROUGH`[3] in a custom triplet[4]. This Stack Overflow answer[5] (full disclosure: I wrote it) explains why you have to do this.

> I would like to be able to tell CMake "for this build, use source folder /foo for dependency "foo"

Use `FetchContent_Declare` with `SOURCE_DIR`[6; this leads to `ExternalProject`, but everything you can use there you can also use with `FetchContent`]. e.g.

  FetchContent_Declare(fmt SOURCE_DIR "${CMAKE_CURRENT_LIST_DIR}/../thirdparty/fmt/")
  FetchContent_MakeAvailable(fmt)

> How do you handle dependencies that takes ages to build.

Link vcpkg's asset and binary caches to a network drive that all developer terminals can access straightforwardly. S3, Azure, GCP, GitHub, local/network filesystems are all supported[7][8].

[1]: https://learn.microsoft.com/en-gb/vcpkg/concepts/overlay-por...

[2]: https://learn.microsoft.com/en-gb/vcpkg/get_started/get-star...

[3]: https://learn.microsoft.com/en-gb/vcpkg/users/triplets#vcpkg...

[4]: https://learn.microsoft.com/en-gb/vcpkg/concepts/triplets

[5]: https://stackoverflow.com/a/77954891/1654223

[6]: https://cmake.org/cmake/help/latest/module/ExternalProject.h...

[7]: https://learn.microsoft.com/en-gb/vcpkg/users/assetcaching

[8]: https://learn.microsoft.com/en-gb/vcpkg/consume/binary-cachi...

[jcelerier]

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

[delta_p_delta_x]

> 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.

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-...