[workspaces] conan build is broken

[theodelrieu]

Hello,

I'm running Conan 1.13.2 with workspaces. I successfully migrated my project to use them, however some of our devs are used to conan build, which is broken with current workspaces.

When running conan workspace install, the top-level build directory only contains conanworkspace.cmake. After running CMake and building, it will contain built artifacts.

If I then want to run conan build my_subproject, I have to provide the install folder (which is the subproject's build folder, which I think is an issue as explained in #4800). But since it has no knowledge of conanworkspace.cmake (since the top-level CMakeLists.txt is not processed), it fails to find its dependencies located in the workspaces, thus the link fails.

To help us debug your issue please explain:

• I've read the CONTRIBUTING guide.
• I've specified the Conan version, operating system version and any tool that can be relevant.
• I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

[theodelrieu]

Another downside is that I must provide CMake flags myself, even though they are mapped to conan options and set in the recipe. That's a huge problem in CI scripts.

[lasote]

We will take a look, but at first sight, you use workspaces to avoid using conan build, right? I don't know if it makes a lot of sense to try to mix them together. As I see it, they are different workflows, you can still do the conan build but you will need to perform the conan install in a build subfolder, that won't be "in the workspace control".
About the second comment, is that a general downside of the workspaces or is it also related with the conan build need? In general, not having the flags generated for the build helpers available to be used without Conan (calling cmake directly) is a very known issue and it is in the roadmap, many issues at the "build helpers" project are related to that.

EDIT: Do you maybe want to do the conan build to generate the cmake stuff to have also available the things adjusted from the build helper and then keep building with the workspace?

[theodelrieu]

conan build also has the --configure --test --build flags which are quite handy. But the main issue is the second comment indeed (i.e. build helpers).

Do you maybe want to do the conan build to generate the cmake stuff to have also available the things adjusted from the build helper and then keep building with the workspace?

Do you mean that running conan build --configure for every subproject would be sufficient in this case?

[lasote]

Unfortunately not today, but yes, that's the idea in the roadmap.

[theodelrieu]

Hello,

I'm bumping this issue with a reproducible case:
workspace-bug.zip

Note that:

• build/libB/conanbuildinfo.cmake has all the information about libA, but doesn't seem to find it
• removing the libA build step from run.sh produces the same behaviour, excepted that libA was not built at all

[kenfred]

It is valid to use workspaces and conan build together. We rely on this heavily.

In our case, we have several packages that we keep in a monorepo. Packages have their own conanfiles so they can declare their own dependencies (whether they be external packages or they be co-resident in the monorepo). Any package in the monorepo that needs to be built as a root package needs a workspace yml so it can locate the co-resident packages in the monorepo. We check in these workspace files in git. and have no immediate intention to ever export these packages.

The root package has a confile with a build method. That is, were using the conanfile.py for consumers paradigm and it's very handy to have the build method with all of the settings/options/profiles abilities.

Unfortunately, we can not update to 1.13.2 and later because of the workspace changes and the current cmake generator is not useful to me.

[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