From reading the documentation it's not really obvious to me how conan handles ABI incompatibilities resulting from different C++ standard versions. I could create a package that would pass a std::list to the package user. Depending on the C++ standard compiler setting the user would expect objects of different size -> undefined behavior.
compiler and compiler.version are settings. conan generates different packages when settings change. So Conan will download the package that matches with your settings. In case, for example, of a header only library, package mantainer can "disable" compiler and compiler.version settings, so the package will be the same for all compilers. What do you think? Do you think it should work?
What would the schema be for storing compiler settings? Those would be of almost arbitrary complexity. Maybe if you combined the os/compiler name/compiler version/settings/deps versions, etc into a an alphabetized spaced delimited string and hashed that or something. idk...
The majority of compiler options don't affect calling convention or class layout, so shouldn't make object files incompatible. They could be whitelisted and omitted.
But preproc flags will. How does this tool deal with that? Just recompiles on every request for a certain config? Why is this better than a repo that has crossplatform-buildable code that is downloaded and compiled locally? Like nuget but cross platform?
