cmake-workspace ?

[ecoezen]

Hi all,

With Conan 2 workspaces nearing the end of incubation, and given how mature the cmake-init project is for setting up clean, standalone CMake projects, I’d like to open a discussion about extending its support to cover mono-build style environments—where multiple interdependent projects are developed and built as part of a larger product.

In real-world setups, we rarely work with just a single isolated project. Instead, many of us manage larger products composed of multiple libraries and applications, built together in a shared workspace. This creates several pain points:

• Conflicting Targets: Common targets like lint, spell, or check often collide across subprojects when aggregated in a mono-repo.

• Workspace-Level Targets: There's no standard way to invoke a workspace-level check, test, or install that delegates to all subprojects.

• Dual Compatibility Is Messy: Developers often patch their CMake logic to work both within their internal workspace and as a standalone package when open-sourcing. These patches are usually hacky and hard to maintain.

Proposal
I believe a workspace template, aligned with cmake-init’s philosophy, would provide significant value:

1. Consistent Workspace Layout: A standard way to organize and structure a Conan 2 + CMake workspace.

2. Forwarded Targets: Workspace-level targets that cleanly delegate to all subprojects without conflict.

3. Isolation Support: Each subproject remains clean, standalone-compatible, and unpolluted by workspace-specific hacks.

4. Tooling Compatibility: Better integration with Conan 2’s new workspace model.

This would not only reduce duplication and inconsistencies across open-source and internal builds, but also help drive adoption of modern CMake practices in larger, more realistic development environments.

Would it make sense:

• Add a workspace-init template (in this or a sibling repo)?

• Provide examples or guidance for adapting cmake-init projects to workspace setups?

• Define conventions for shared tooling targets (e.g., workspace-wide lint, format, test)?

Would love to hear thoughts from others who work with multi-project builds, and whether this aligns with your challenges and workflows.

Best,