search

conan-io / conan

Conan - The open-source C and C++ package manager
https://conan.io
MIT License
7.95k stars 951 forks source link

[question] Motivation behind conan v2 cache design #16471

Closed rconde01 closed 5 days ago

rconde01 commented 2 weeks ago

What is your question?

I'm curious about the more opaque design behind the conan v2 cache in comparison to the v1 cache. I assume this is to better address path limitations on Windows. Is this correct? Are there other reasons?

Have you read the CONTRIBUTING guide?

memsharded commented 2 weeks ago

I'm curious about the more opaque design behind the conan v2 cache in comparison to the v1 cache. I assume this is to better address path limitations on Windows. Is this correct? Are there other reasons?

It is not only Windows, but the fact that the cache can host multiple revisions of the same package. As the revision can only be computed after the recipe is exported or after the binary has been built, it has to be stored in temporary folder (that is created with unique-ids), and after the build relocating the build folder often is more problematic (caches, rpaths) than keeping them in the temporary folder. Also, there are tools that have limits to its arguments, in different ways, from Windows maximum command line argument of 8191 characters, or some tools or compilers. Note that if we used full paths including the recipe-revision + package_id + package_revision, those are really long paths. Taking into account that revisions or package-ids are not really human understandable either, they provide very little added value to be explicit, and the translation between references and folders is just one conan call away.

memsharded commented 5 days ago

Closing as responded, please re-open or create new tickets as necessary for new questions. Thanks!