[workspaces] Build all projects using one command

[uilianries]

To help us debug your issue please explain:

Hi!

First of all, I would like to congratulate all team. It's amazing to see Conan project feature starting to getting life.

I'm curious if workspace will be supported by create command. My idea is create multiple packages using workspace. The current example uses install to generate the cmake files, followed by cmake command. Would be nice to have conan create to execute all steps with no cmake lines.

Also, I didn't find support to test_package. Will it be supported?

Conan version: 1.4.4

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

[memsharded]

Hi!

But do you mean a conan create to create packages in the local cache, as always? Yes, this is likely to be a future extension, shouldn't be very difficult to implement, just that at the beginning we are focusing on the local development which is the most challenging part. If that is OK, then, we envision commands like conan worskpace create, conan workspace open MyPkg, etc, that could further improve the usage.

[uilianries]

Great!

Another suggestion, I have helped @taocpp to include Conan support on their projects. @d-frey asked to use a sub directory to hide test_package and build.py. The request makes sense to me, but would be really great if Conan workspace supports custom test_folder (path) for the project.

For now we just use conan create . -tf <path> but with workspace we could run conan workspace create and test_package path will be in conanws.yaml

And finally, I'm curious why did you use the file name conanws.yml instead of conan.yml? Is there some idea to use the name conan.yml for another propose in the future?

Regards

[memsharded]

And finally, I'm curious why did you use the file name conanws.yml instead of conan.yml? Is there some idea to use the name conan.yml for another propose in the future?

It is likely that other files will be used, for example "lock" files, or maybe something related to CI. Naming it with "ws" made sense to make sure the name identifies the purpose.

I'll take it into account, for the test_package build folder, when the conan workspace create is considered, thanks!

[uilianries]

Thank you!

I'm going to close this issue for now. For any new question I'll re-open it.

Regards!

[memsharded]

No, I think it is better to keep it open, to gather feedback of other users. It is something that is likely to be developed, so no need to close at the moment. Thanks

[GarrickLin]

Any progress on conan workspace yet ?

[mbodmer]

I think to let conan generate a CMake superbuild is a good idea to create workspaces. However the way the CMake superbuild is currently implemented is not so great yet.

Current problems using add_subproject are:

• Subprojects are not isolated, they all share the common CMake defines
• Conan receipes are not really reused for the build (as source for subproject CMake defines)
• find_package(subproject) won't work out of the box, especially using cmake_paths generator

IMO it would be a better fit to implement workspaces using ExternalProject_Add and create a "standard" CMake superbuild. Instead of add_subdirectory, something along the lines of :

  ExternalProject_Add(${PKG_NAME}
    CMAKE_ARGS <<pass along args from superbuild CMakeLists>>
    CMAKE_CACHE_ARGS <<args from conan receipe>>
    DEPENDS <<dependency information from conan receipe>>
    SOURCE_DIR <<local package source dir from conan receipe or layout>>
    BINARY_DIR <<binary dir from layout or same as superbuild (as default)>>
    DOWNLOAD_DIR <<set to same as source dir so no download is needed>>
    INSTALL_DIR <<define in layout>>
    BUILD_ALWAYS 1
    USES_TERMINAL_DOWNLOAD 1
    USES_TERMINAL_UPDATE 1
    USES_TERMINAL_CONFIGURE 1
    USES_TERMINAL_BUILD 1
    USES_TERMINAL_TEST 1
    USES_TERMINAL_INSTALL 1
  )

That way a user-supplied top-level CMakeLists.txt is maybe not nessesary anymore as it's not needed to tweak by the user. It should be possible to take all the information from the conan receipes and mybe the layout file.

references:

• https://blog.kitware.com/cmake-superbuilds-git-submodules/ (Developer Build)
• https://subscription.packtpub.com/book/application_development/9781788470711/8/ch08lvl1sec89/managing-your-project-as-a-superbuild

[memsharded]

Conan editable mode already support --build=editable in 2.0, closing this as solved.

Workspaces were removed in 2.0, but the plan is to resume work on them in the 2.X roadmap. Please track progress in https://github.com/conan-io/conan/issues/12466, closing this