Sounds good! I think I’ll do that as my next topic!

Unfortunately I’m not well versed in vanilla VS - I only have built VS projects generated by CMake as I primarily develop code on Linux.

Each project should use find_package() to go find dependent projects. The superbuild dependency tracking is about making sure each project is built in the correct order -- it doesn't actually affect the underlying project's CMake itself. In this case, all projects which use rkcommon each do their own find_package(rkcommon) and then link exported rkcommon targets, which is where things like include paths and library files get incorporated.

Yes, in the multi-project example you see TBB_ROOT specified as a CMake argument to each project to find the TBB that was extracted locally. As for emscripten, I haven't used that toolchain before so I'm not familiar enough with it to know how one should approach dependencies. I would hope that there's a way to find_package() libraries built with emscripten (?), but I'm not sure how much native CMake can handle that beyond header-only interface libraries. Sounds like an important problem to solve! One thing I've been experimenting with lately are "source libraries" (not sure if there's an official name for it). The idea is that you can use target_sources(${TARGET} INTERFACE sourceA.cpp sourceB.cpp ...) on an CMake interface library target, which will then propagate the cpp files themselves downstream to targets which link it. This is problematic if you don't control all the dependencies, but is definitely an option if you are able. If anything, you could create a superbuild of external projects with your own custom CMakeLists.txt for each project that creates a "source library" of each one manually. However, because there isn't really a build step for these types of "source only" libraries, you could just do it with FetchContent instead all in the furthest downstream consuming project's CMake build.

@@jeffersonamstutz I do not think it is feasible with FetchContent as it does not set the *_ROOT variable. So if you need a library A which depends on library B, you need to first download and compile library B. Library A uses find_package(B) which would try to look in system folders, which is not desired. FetchContent does not set *_ROOT variables. This guy invented a wheel kzfaq.info/get/bejne/g8yldbZq05vDkY0.html&lc=UgwlVI4oxNHL8Os3fft4AaABAg.9RcmsnQR_6E9RcqDPaKY30 And there is this proposal as well: gitlab.kitware.com/cmake/cmake/-/issues/21687

To get external dependencies into your build you will need find_package(), but ExternalProject runs at build time which is after when CMake would search for it during configuration. The best thing to do is to write your project that builds only itself and maintain a separate CMake superbuild that can string together ExternalProject invocations. You certainly could mix these in the same directory structure by only invoking your executable’s CMake from a parent folder containing the superbuild. You would do this by having the ExternalProject invocation bypass the download step and point directly to your local source directory. Be careful though - it is bad practice to always assume overly rigid dependency handling by requiring that you can only use the deps built locally.