[feature] conan workspace build command

[aander80]

What is your suggestion?

Hello!

As part of the workspace feature (#15992), I would like to have a conan workspace build command. The idea is that it would resolve the dependency graph and build missing editable packages in the cache (I expect that here, you would need to build all and rely on the underlying build system caching the build artifacts correctly).

In my example repo where I am testing workspaces, I am thinking that I should be able to run conan workspace build and it will first build liba and libb, followed by app (app is an executable depending on static libraries liba and libb).

This would allow users to mimic a monorepo with multiple repos, and have a nice CLI similar to what you have with cargo build with workspaces in Rust.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @aander80

Thanks for your suggestion.

I agree that this could be useful, and it is something we will discuss in next steps

At the moment, you can do:

conan build app --build=editable

This will build liba, libb and app in the right order, because it resolves the dependency graph (you can use profile and settings arguments, of course).

The conan workspace build would be a bit of a higher level syntax over than, where mainly the "root" package of the workspace (in this case the app) is defined in the workspace files. This is one of the aspects that we need to think, as it is possible to have different "roots" in workspaces.

[aander80]

At the moment, you can do:

conan build app --build=editable

Thanks, I was looking for a command like that! :)

The conan workspace build would be a bit of a higher level syntax over than, where mainly the "root" package of the workspace (in this case the app) is defined in the workspace files. This is one of the aspects that we need to think, as it is possible to have different "roots" in workspaces.

Would it make sense to check

• If there is a single root, build that
• If there are multiple roots and none is specified in the command:
  • Error
  • Build all roots
  • Something else?

I expect that it would be useful to specify conan workspace build <root> to a specific node in the workspace as root; this could be any of liba, libb and app, and is similar to cargo build --bin <name>.

[memsharded]

If there are multiple roots and none is specified in the command:

Yeah, this is exactly the kind of thing that needs to be considered. I think that it might be possible to iterate the builds of several roots. We also have the conan graph build-order capabilities, including merging build-orders, so this is definitely doable in an efficient way, but we also have to consider the complexities of implementation, the UX, etc.

I expect that it would be useful to specify conan workspace build to a specific node in the workspace as root; this could be any of liba, libb and app, and is similar to cargo build --bin .

If that maps to conan build app then probably it is more boilerplate than helpful.
But maybe what makes sense is to configure something in the workspace itself that can default the --build=editable if desired.

[aander80]

But maybe what makes sense is to configure something in the workspace itself that can default the --build=editable if desired.

Yeah I expect that for the most part you would want that behavior by default, but I can also see cases where you would only want to build a single package but still use the editables from the workspace; a very simple example of this is if you have 10 libraries and building, even with caching, takes as little as 3 seconds, then you need to wait for 30 seconds for the application to even start building every time.

I am thinking that if default behavior is to build a single node in the workspace graph (e.g. conan workspace build app builds only app but not liba or libb), then you could run conan workspace build app --build=workspace which would build all nodes in the workspace that are included in the dependency tree from app.

For the most part, I guess that --build=workspace would be the same as --build=editable, but there are of course edge cases where you have statically configured editables outside of your workspace that you may not want to build.´, and --build=workspace is perhaps more explicit and intuitive.