Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[workspaces] Handling of transitive requirements broken #4720

Closed
sigiesec opened this issue Mar 12, 2019 · 6 comments
Closed

[workspaces] Handling of transitive requirements broken #4720

sigiesec opened this issue Mar 12, 2019 · 6 comments
Assignees
Milestone

Comments

@sigiesec
Copy link
Contributor

With conan 1.13.0, the handling of transitive requirements appears broken. I don't have a reproducible test case right now (I can try to construct one), but the situation is as follows:

I want to have a workspace with packages A and B. A depends on C, which has a transitive requirement on D. B depends on D directly.

If I run a regular conan install for A, the conanbuildinfo.cmake contains the definitions for C and D, in particular the CONAN_CMAKE_MODULE_PATH contains both C's and D's directories, which is necessary to process the cmake files of C.

However, with conan workspace install, only B's conanbuildinfo.cmake contains the definitions for D, while A's conanbuildinfo.cmake containts only the definitions for C, which leads to cmake errors, since D's cmake modules cannot be found.

@memsharded
Copy link
Member

While having a look at this issue I discovered a bug with the management of multiple "root" packages in a workspace. I have submitted a fix in #4722

It was failing when declaring:

 editables:
                HelloD/0.1@lasote/stable:
                    path: D
                HelloB/0.1@lasote/stable:
                    path: B
                HelloC/0.1@lasote/stable:
                    path: C
                HelloA/0.1@lasote/stable:
                    path: A
            layout: layout
            root: HelloA/0.1@lasote/stable, HelloB/0.1@lasote/stable

Once the bug is fixed, it seems that the conanbuildinfo.cmake files of each editable package contains the right information. It is necessary to have a [build_folder] in the used layouts.

Please have a look to the test here: https://github.com/conan-io/conan/pull/4722/files. Thanks!

@memsharded memsharded added this to the 1.14 milestone Mar 12, 2019
@frankwalentowski
Copy link

sigiesec forgot to mention, that A depends on B and A will be the only one root. So i don't think, that #4722 will solve this issue. I try to build a minimal example to demonstate this issue,

@frankwalentowski
Copy link

I build a minimal example, where 'HelloA' requires 'HelloD', 'HelloC' and 'HelloB'; 'HelloB' requires 'HelloC' and 'HelloC' requires 'HelloD'. Exporting 'HelloD' and 'HelloC' into local conan cache and try to build a workspace with 'HelloA' and 'HelloB' as editables and 'HelloA' as root, than the transient dependency error occures on generated 'conanbuildinfo.cmake' file of 'HelloB'.

conan_workspace_bug_min.zip

When you compare the conanbuildinfo of 'HelloB' generated by 'conan workspace install' with a version of 'conan install' directly for 'HelloB', you will see that 'CONAN_HELLOD_ROOT' etc. is not generated and 'HelloD' conan cache path is not listet in 'CONAN_CMAKE_MODULE_PATH' in workspace version.

conanbuildinfo_HelloB.zip

@memsharded
Copy link
Member

Thanks very much @frankroeske for the reproducible case. Really useful.

Indeed, it seems the graph resolution algorithm had a bug, I have submitted a possible fix in #4737, and we will try to release it in a Conan 1.13.1 release, as soon as possible. Cheers!

@memsharded memsharded modified the milestones: 1.14, 1.13.1 Mar 14, 2019
@frankwalentowski
Copy link

frankwalentowski commented Mar 14, 2019

@memsharded Thank you! This fix solves the bug also in our complex case 😃 .

@lasote
Copy link
Contributor

lasote commented Mar 15, 2019

1.13.1 released, please report again if something still fails.

@lasote lasote closed this as completed Mar 15, 2019
@ghost ghost removed the stage: review label Mar 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants