Using cget to manage dependencies that are constantly evolving together with main library

[Allan Leal]

Let's say I have a library project lib and another called dep, such that lib depends on dep. Both libraries are very dynamic - they are changing all the time, and I want to make a quick change in dep and this be easily captured in lib.

How would you recommend the use of cget for a convenient workflow when developing these two (or more) libraries in parallel?

I'm trying here something like:

1. lib and dep live in the same directory.
2. Inside lib, I do cget install --update ../dep
3. cmake is checking inside the cget dir for the dep library (using the toolchain file).

My issue here is that install --update compiles the library from scratch, instead of an incremental build.

After trying git-submodule and having several issues with it, I'm giving cget a try.

[Paweł Kubik]

Never tested something like this but you could possibly pass --build-path to the cget build to set it up in some sane place and then manually run make && make install in the build directory.

[Paul Fultz II]

How would you recommend the use of cget for a convenient workflow when developing these two (or more) libraries in parallel?

Are these two libraries cmake libraries? The best is to use cmake and include both libraries with add_subdirectory in the superproject.

My issue here is that install --update compiles the library from scratch, instead of an incremental build.

We could add a flag to keep the build directory so an incremental build is possible, but I dont know how well that will always works.

cget makes a copy of the local directory because sometimes it modifies the source directory to inject the cmake file(when using the --cmake flag). However, this copy might make it always rebuild anyways due to every fill being copied in.