You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wonder what is the reason for the following restriction from the conan docs:
In the client cache there is only one revision installed simultaneously.
I'm thinking about how to organize reproducible builds. In general this could be achieved by requiring certain package revisions for certain commits. But here we come to issues with build time optimization. In our project we have multiple long-living branches for multiple simultaneously supported product versions. These branches sometimes require the same version of some dependency but that dependency could have different revisions (e.g. one of its dependencies were updated, or we patched the package somehow to fix build issues). Thus when a developer work on two or branches she has to rebuild parts of the project when she switches branches (because conan will install another revision of the package to the same location). Under "switch" I don't mean something like git checkout what will obviously re-build a lot, I mean that a developer just goes to another working directory.
Currently we add additional revision suffix to package versions for such cases, but I don't like that approach because:
we have to encode some metadata to a package which does not relate directly to version of the package
we have to do it manually in the package itself.
Maybe conan could have an opt-in options to allow simultaneous installation of multiple revisions?
The text was updated successfully, but these errors were encountered:
This is just an implementation limitation. Introducing revisions without breaking was really challenging feature, and this limited implementation allowed to simplify a lot of things and roll-out the revisions.
Maybe conan could have an opt-in options to allow simultaneous installation of multiple revisions?
Yes, this is planned. Still not in the short term roadmap, because there are other higher priorities, but most likely for Conan 2.0 this will be considered.
It may be good idea to add command-line flag during conan create to handle package as separate revision.
My use case:
I want to store large conan package (conan package for LLVM) in local cache, each revision with with different options but same version.
Currently i'm forced to re-build LLVM (takes hours) on each change in options (ideally common configurations of LLVM package options must be cached by some flag during conan create)
Note that LLVM takes a lot of disk space, so i want to cache (store revisions) only for most used configurations of LLVM package options.
As temporary solution: client can build package locally, use separate folder for each option set. That approach allows to enable only one option set globally using conan export-pkg (but if you want to handle multiple option sets at the same time - you are forced to use separate conan server)
Conan 2.0 already implements a multi-revision cache, already available in 2.0.0-alpha1, this can be closed, feedback welcome if you can test the 2.0-alpha, thanks!
I wonder what is the reason for the following restriction from the conan docs:
I'm thinking about how to organize reproducible builds. In general this could be achieved by requiring certain package revisions for certain commits. But here we come to issues with build time optimization. In our project we have multiple long-living branches for multiple simultaneously supported product versions. These branches sometimes require the same version of some dependency but that dependency could have different revisions (e.g. one of its dependencies were updated, or we patched the package somehow to fix build issues). Thus when a developer work on two or branches she has to rebuild parts of the project when she switches branches (because conan will install another revision of the package to the same location). Under "switch" I don't mean something like
git checkout
what will obviously re-build a lot, I mean that a developer just goes to another working directory.Currently we add additional revision suffix to package versions for such cases, but I don't like that approach because:
Maybe conan could have an opt-in options to allow simultaneous installation of multiple revisions?
The text was updated successfully, but these errors were encountered: