[bug] Conan workspace ignores shared option

[asarayev]

• Operating System+version: Ununtu 20.04
• Compiler+version: clang5
• Conan version: 1.33.1

I have a workspace with a few packages and one of them is supposed to build into a shared library. In the conanfile.py for this package I have

options = {
    "includeMocks": [True, False],
    "shared": [True, False],
    "fPIC": [True, False],
}

default_options = {
    "includeMocks": False,
    "fPIC": True,
    "shared": True,
}

When I build it as a single package everything is fine but when I create it as part of the workspace it is built into a static library. I see in the log that option shared works and it is true but later in build.ninja it says # Link the static library.... So it seems like it simply ignores this option. Put shared=True in the conan workspace install command doesn't change anything too.

[memsharded]

Hi @asarayev

That is unexpected, yes. I have been checking the code, and so far cannot reproduce it, there seems to be nothing intrinsic to the workspace that would change such option value. We would need more details, something like a minimal reproducible case in a zip or github repo would really help.

Also, please beware that workspaces is an experimental feature, that hasn't been getting any efforts in a long time. This is because we are trying to improve first some of its foundation, specifically the "editables" and the layout() definition, because that is really important as an initial building block for workspaces. But the workspace itself might still have a bunch of rough edges. We will eventually resume work in this feature, but it is not in the short term roadmap.

[asarayev]

Hi @memsharded

I've quickly created a new repo for this. So if I build test_package as a standalone conan package, it creates a shared library. And if I create it from workspace it creates a static library. And I don't see a way how to force it to create shared library from workspace.

[memsharded]

Hi @asarayev

Thanks for your reproducible case, it really helped to identify what is happening.
The problem is the cmake integration uses a lot of configuration passed in the command line from the build() method. When the build() method is not called directly, because you are in a workspace, this configuration will not be passed.
This is the case of the BUILD_SHARED_LIBS cmake variable.

We have already delivered a new integration which handles this a bit better: CMakeToolchain will generate a conantoolchain.cmake toolchain file that will included the BUILD_SHARED_LIBS for that package, and can be used in the command line for one package. The limitation is that every package in the workspace will need to use its own toolchain, and therefore, workspaces global project will not work as-is. We need to investigate this, so far it seems like a single, monolithic CMake project will not be possible, and workspaces will work as a coordination of individual, possibly heterogenous projects.

Sorry, it doesn't seem easy a short term solution for this, as I said before, workspaces are still experimental, and we need to address some other more basic components first before working again on this feature.

[lasote]

We should investigate if replacing add_subdirectory with ExternalProject_Add gives us the possibility of declaring the toolchain for each subproject.

Using the CMAKE_ARGS you can pass a -DCMAKE_TOOLCHAIN_FILE

[memsharded]

This should have been solved by the new Workspace in Conan 2, closing the ticket.

It is in incubating: https://docs.conan.io/2/incubating.html. But please give your feedback in #18263 or create new tickets as necessary. Thanks for your feedback!