fixing transitive order of privates #4987
Please find here a new patch for Conan 1.14.4 for the processing of
It happens that the build-requires and private usage is way more complicated that what the model was designed for. We are trying to propose fixes and improvements to achieve both a safe dependency resolution (linking with the right dependency, conflicting if not defined) and those complex graphs Conan didn't intended to support initially (but we are doing our best to try to adapt).
I've tried that patch on both may old codebase and new one (after making update as suggested in your comment. The old one reports conflict, just like with conan v1.13+ and as demonstrated in minimum sample attached to the same issue and the new one works the same as with conan v1.14.3. Basically, I haven't seen any changes to that part of my package management from v1.14.3 to v1.14.4.
Basically, for us its the same as for @theodelrieu - nothing broke
Oye, I apologize for being late to the party. I had an example thrown together last night, but it was getting late so I opted to committing it in the morning... looks like that was a mistake.
As for my original example with our shared COM dlls, I think the solution is to use
So in that specific case, I think we were misusing
However, in the same project, we're also using the header only library Boost, and I believe that raises some questions about the way "private" requirements are resolved that are worth considering.
So, yesterday, I worked with @puetzk to come up with a more illustrative example of some potential issues we see with the new approach to "private" requirements in 1.14.4.
The primary concern is that the 1.14.4 "private" requirements could result in One Definition Rule (ODR) violations if a shared package uses header only or static libraries in such a way that they are
My new examples attempt to illustrate this by using "mock" packages of two popular libraries, Boost and zlib.
When using Boost in header only mode, all users of Boost must maintain
On the other hand, libraries like zlib make very strong semver ABI guarantees. A consuming app using a newer semver compatible version of zlib could, in theory, override the version of zlib used by one of its required packages.
But in both cases, Conan 1.14.4 resolves these requirements and "private" requirements in such a way that both versions of Boost and zlib are present in the consuming package... which seems problematic.
You can find that here:
We can work around this issue by promoting these "private" requirements to full on requirements, and then the overriding will work, but it seems a little odd to make "public" requirements on Boost / zlib when they're not at all exposed through the public API of our shared library.
Hi, I should have tried on my side project beforehand... I get the following assert:
With 1.14.4, sorry about that!
You can reproduce by checking out the