[question] How to Skip Recompilation of Modules When Updating a Shared Library Version in a C++11 Project?

[Neha200794]

What is your question?

Hey

I’m working on a C++11 project that uses Conan2 for dependency management and CMake for building. The project has a structure like this:

Libraries: libA, libB, coreLib Modules: 22 modules, like module1, module2, etc. (All depends on coreLib) Main Executable: MainApp depends on all libraries and modules.

The coreLib is a shared dependency across all modules. When I make any changes to coreLib, it results in a new version (e.g., from coreLib/1-release to coreLib/2-release).

Currently, this requires me to:

1. Manually update the version of coreLib in each module's conanfile.py.
2. Recompile all the modules with the new version.
3. Build the MainApp executable with the updated modules.

Challenges I'm Facing:

1. Recompiling all 22 modules takes around 2 hours, even when changes in coreLib are internal and don’t impact the module interfaces.
2. If I don’t recompile a module, I run into version mismatch issues when building MainApp, as some modules may still reference coreLib/1-release while others use coreLib/2-release.
3. I’m looking for a way to skip recompilation of modules when it’s not needed, ideally automating this process.

What I’ve Tried:

1. I explored using override=True in the conanfile.py but encountered issues when versions didn’t match.
2. I also considered using conan lock files for managing consistency, but this doesn’t solve the recompilation problem directly. Question:

Is there a way in Conan to manage this scenario more efficiently, such as: Allowing modules to use different versions of coreLib during the build of MainApp without triggering recompilation?

Any guidance or best practices for handling such dependency updates would be greatly appreciated!

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @Neha200794

Thanks for your question.

The most important point is to follow a more standard versioning approach, instead of from coreLib/1-release to coreLib/2-release. These versions are very important, check for example https://docs.conan.io/2/reference/binary_model/dependencies.html

This means that you should be doing:

• Patch versions when no re-builds are necessary in the consumers
• Minor versions bumps when re-builds are necessary in the consumers, but API compatible, so everything is expected to compile
• Major version bumps when there are breaking API changes that require changing the C or C++ source code of the consumers of the package.

These also are intended to work nicely with more standard version ranges like requires = "mypkg/[>=1.0 <2]" that naturally excludes the major version bumps with the API breaking changes, but automatically accepts patch and minor version bumps that might require a re-build or not, but are expected to integrate without changing the source code.

[memsharded]

There is also a discussion in the future CI-tutorial (see open pull request in https://github.com/conan-io/docs/pull/3799), specifically the Default versioning approach section, that might be relevant.

[Neha200794]

Thanks for the quick response.

What about override=True? can that be used in this case? Also, for your suggested case, will the final MainApp have both the versions pulled or only the latest one?

[memsharded]

What about override=True? can that be used in this case?

Overrides wouldn't be recommended in most cases, just as a temporary workaround for resolving dependencies conflicts. I'd discourage using them for anything else. Furthermore, the overrides do not affect the package_id model, which defines in turn what needs to be recompiled, so I don't see how this could help in this case.

Also, for your suggested case, will the final MainApp have both the versions pulled or only the latest one?

In most cases, a dependency graph can only contain 1 version for a given library. It is possible under some circumstances and using advanced features to change this behavior, but in general this shouldn't be done. So if your graph resolve to version 2, then that will be the one. You will see what packages are resolved in the output of conan install