Cache Gets wrong package[bug] about conan HOT 8 CLOSED

What I see in that message is an error building boost, I don't see any conflict:

[ERROR:vcvars.bat] Toolset directory for version '14.3' was not found.
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***

It could be that they don't have that toolset installed in their Visual Studio installation?

In any case, this would be a different thing. The original issue about the package seems to have been solved, and the issue was that your friend had some stale/old packages in their cache, updating it seems to solve the issue.

I'd recommend to close this ticket as solved, and open a new one specific for the new issue (not sure if it is boost not building or a conflict with zlib, but please provide the specific output and the new details to reproduce). Thanks!

from conan.

Thanks man, you are right about the original issue being fixed! I will see if we can't work out the reason he is not able to build boost before opening a new ticket.

from conan.

Hi @Codinablack

Thanks for your report.

I don't think this is a bug, but expected behavior.

The first important bit to take into account: please don't share the same cache among different machines. The Conan cache is not concurrent, so having 2 machines accessing the same cache can easily result in race conditions. The recommended flow is to upload the binary packages built with one machine to a package server, like the free ArtifactoryCE in our downloads page.

Then, what you are seeing seems to be the default behavior of the default compatibility.py plugin. Please check: https://docs.conan.io/2/reference/binary_model/custom_compatibility.html#the-compatibility-py-plugin, but in general the whole section is relevant: https://docs.conan.io/2/reference/binary_model

That is, packages built with different compiler.cppstd are assumed to be binary compatible. This is a good default that works well in the majority of cases. For other use cases you can:

• Change the default behavior of the compatibility.py plugin
• Disable in the package conanfile.py recipe the default compatibility with extension_properties = {"compatibility_cppstd": False} (read https://docs.conan.io/2/reference/extensions/binary_compatibility.html#reference-extensions-binary-compatibility)

Please let me know if this clarifies the behavior.

from conan.

Thanks for the quick response, but I feel there is a bit of confusion here. I am not sharing binaries. I am only sharing sources and conanfile.py, along with a setup_build.py, and a premake5.lua (premake is the build app I use, instead of cmake). These are the only things shared between the two machines, and the setup_build.py just runs conan and premake for me.

I am not using any custom recipes, I am only using the conan center. I would expect when using the conanfile.py, on two windows machines, to get the same packages...

from conan.

Ok, I understood it wrong.

Can you please share the full output of the conan install command for those 2 different computers?
Also I understand you are using packages from ConanCenter?

Please make sure to completely wipe the Conan cache in both computers before trying the conan install, to make sure you don't have anything different cached in those computers.

from conan.

How can I completely wipe the conan cache? One computer is fine, everything works perfectly and as expected, the other however, not so much.

I am using the packages from conan center from the example for each of those packages, the conanfile.py example. Here to clarify what my file looks like..
conanfile.txt

I had to change it to a text file because python files are not allowed to be uploaded

from conan.

How can I completely wipe the conan cache? One computer is fine, everything works perfectly and as expected, the other however, not so much.

The packages cache can be done with conan remove "*" -c. Completely wiping everything is just removing the ~/.conan2 folder (or wherever the CONAN_HOME is pointing to)

Yeah, you can wipe the one that is not working and then repeat the conan install and share the full output.

from conan.

message(3).txt
Here is a text file containing the output from the machine I am having a problem with. It was a friend who was issueing the commands and such, it appears he may have used the same notepad to copy multiple outputs. Anyways, it seems that clearing the cache fixed the problem with the three libs it was issueing the wrong versions for, but for some reason, there is still a conflict with zlib for some reason, which is keeping my friend from being able to compile.

from conan.