[workspaces] Propagation of default options for transitive dependencies

[onnodb]

We've been trying out the revamped "workspaces" feature in Conan 1.13. My tests have been done using a project using CMake 3.13 on Windows, with the MSVC toolchain.

We have a project that consists of:

• a consumer project C, with dependencies on package P and library A;
• a homegrown package P, that also depends on A;
• a library A with a conanfile.py that provides an option called shared.

The conanfile.py for C furthermore has the following line:

class CConan(ConanFile):
    # ...
    default_options = "A:shared=True"

The workspace feature gives us a nice local editing workflow for C and P. Following the (very clear!) instructions in the documentation, we create a workspace.yml file:

editables:
  C/1.0.0@example/testing:
    path: C
  P/1.0.0@example/testing:
    path: P
layout: mylayout
workspace_generator: cmake
root: C/1.0.0@example/testing

Now, when compiling the super-project generated by conan workspace install, we noticed that the A:shared=True option does not seem to be propagated from C to P anymore, resulting in linker errors. This propagation does work absolutely fine when using the normal "editable package" workflow (conan editable), or the normal workflow (conan install).

Thanks for your help!

[memsharded]

Hi @onnodb

Thanks for your detailed report!

Quick question: Are you getting automatically the conanbuildinfo.cmake in P after doing the workspace install? It is necessary to define the [build_folder] in your layout for this. Doing this, the information of conanbuildinfo.cmake should point to the correct A package (you can see the package ID of A printed in the output of the workspace install command. Please let me know, thanks!

[onnodb]

Hi @memsharded

Thanks for the response, and sorry for the delay in getting back to you.

I just checked, and I see the following:

• There is indeed a conanbuildinfo.cmake in P's build folder. It appears to link to the 6cc50b version of A.
• When building C in the regular workflow, the output from conan install indicates that it's linking to the 970e77 version of A.

So it appears that in the workspace case, options for transitive dependencies might not be correctly propagated. Am I right?

[memsharded]

Workspaces were removed in 2.0, but the plan is to resume work on them in the 2.X roadmap.
Please track progress in #12466, closing this