[question] Can conan sort out package dependency order when using workspace super-install?

[ScottGTI]

What is your question?

I'm using the workspace template (generated from conan new workspace) to explore workspaces with a super-install. When using this template, do I have ensure that add_project() calls must be ordered such that dependencies are declared before they are used?

For example when using the stock workspace template, if I move the add_project(app1) from below add_project(libb) to above it, it will fail to build. The "conan workspace super-install" will complete, however the following call to "cmake --preset conan-release" will fail because it can't find the libb package.

For a large project cmake does a reasonably good job of building the dependency tree such that add_subdirectory() calls do not have be in a specific order. Is there a way to use conan workspaces with a super-project to accomplish this?

In the above setup I'm using Ubuntu 22.04, Conan 2.19.0 and cmake 3.25.2.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @ScottGTI

Thanks for your question.

This is indeed a very good point. I also thought that the FetchContent would behave similar to the add_subdirectory() in that regard, and it would do a better job with the order, but apparently it doesn't.

Conan has the conan graph build-order command that can show you the build order for any graph (with json and html outputs too), so if you give it the path to one of your workspace consumer packages, it will give you the right order.

I have also done #18693, that will print this order directly in the conan workspace super-install command for convenience.

It might also be possible to add CMakeLists.txt-editing capabilities to the workspace commands, like it could automatically re-order the add_project() calls, but at the moment it seems a bit too much, what do you think? If the command gives the order will be enough?

[ScottGTI]

Thanks for your input. It is too bad that the FetchContent doesn't behave well, it's so close.

I looked at the conan graph build-order and it provides a lot of information, but would require a bit of tooling to make work. After looking at the graph output, I would see the following:

• Run conan workspace super-install
• Run a tool that would:
  • Search the local tree to find all of the conanfile.py files. For each conanfile.py
    • Either load or parse the conanfile.py to find the name of the package. I think this step is necessary because the output json for the conan graph command always refers to package names and version, but not the conanfile.py it came from.
    • Run conan graph build-order --format=json
    • Parse the json file to determine build order for that package.
  • Create a global build order based on all of the build orders of the individual graph outputs
  • Write or edit the CMakeLists.txt to add the various projects in the correct order.
• Run cmake commands
• Rejoice!

Does that sound like the necessary steps? Is there an easier way?

I would worry that such local tooling would be rather brittle and may not fit well within the developers workflow. My preference, of course, would be to have conan handle this complexity internally. Some possible approaches:

• Have conan workspace edit the CMakeLists.txt, as you suggested
• Is it possible for conan to export a cmake function that looks something like conan_add_project( LIST OF DIRS ) that just does the right thing?
• If the above tooling is still required, would it be possible to have a conan workspace graph command that provides the build order for the entire super-build?
• Would a conan extension, with access to its rich APIs, be a better place for this tooling?

These are just wild guesses at possible approaches as I'm not familiar with conan internals. I'm sure there are other options as well.

[memsharded]

Does that sound like the necessary steps? Is there an easier way?

Yes, this shouldn't be necessary, as I suggested the change in #18693 is already doing all of that, and printing the correct build-order.

The only missing part is the automatic modification of the root CMakeLists.txt to enforce that order.
But maybe, depending on the case, this might not be necessary? If the workspace is relatively stable, and this changes unfrequently, then it can be easily done manually.

Some possible approaches:

Thanks for the hints.

I think something built-in in the conan workspace makes sense, the first two points makes sense. I'll check what could be done, give it a try for next release.

[ScottGTI]

Thanks for looking into this. I look forward to the next release.