Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] Conan 2 workspace, and integration with IDEs #17723

Open
1 task done
Adnn opened this issue Feb 6, 2025 · 3 comments · May be fixed by #17675
Open
1 task done

[question] Conan 2 workspace, and integration with IDEs #17723

Adnn opened this issue Feb 6, 2025 · 3 comments · May be fixed by #17675

Comments

@Adnn
Copy link
Contributor

Adnn commented Feb 6, 2025

Following #15992 , I could finally give the new workspace feature a try, through conan new workspace.
Thank you for making this a reality!

A brief highlight of our code structure and development workflow:

  1. The functional domains are divided in several distinct repositories (no mono-repo, no git submodule between them), each repo might contain a few libraries and applications (each mapping to a distinct CMake component and a distinct CMake target)
  2. We maintain full compatibility with a CMake only workflow (but Conan makes it so much better to satisfy dependencies ❤ ), so the CMake scripts produce complete XxxConfig.cmake package configurations.
  3. When developers work on a project, they pull all related repositories (== the editables of the workspace), and will usually makes edits in several of them. Developers are using a variety of environments (mainly Visual Studio, VScode, neovim with LSP).

We were able to nicely satisfy all those requirements with the Conan 1 workspaces, since they were mostly a meta CMake project:

  • All CMake targets were showing up as individual targets in the IDEs:
    • We could generate IDE project files from CMake, so each target was properly showing up in IDEs
    • We could leverage VScode CMake extension to directly see CMake targets
  • The CMake targets had correct dependencies between them: making a change to any repository in the workspace would automatically be resolved as required during compilation of any downstream target.

With the Conan 2 workspace, I am not sure how to achieve any of the required IDE integration.
Is there a "meta" CMake project generated somewhere?
How could we get all the targets defined by the editables (as listed in the conanws file) properly show up in IDEs? And recompile all that is needed for the currently active target (and only what is needed)?

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
@memsharded
Copy link
Member

Hi @Adnn

Thanks for your question.

Is there a "meta" CMake project generated somewhere?

yes, it is on the go! :)
So far, in the release 2.12 there is mostly the workspace structure, files definitions, adding/removing editables, etc. Something basic to start iterating.

We are already working in 2 major upgrades for next 2.13:

  • Converting the current conanws.py file definition, to something more similar to conanfile.py, same patterns, same self.conan_data access to the underlying yaml. This is the proposal if you are curious: workspace Python files proposal #17688
  • The second thing is a new conan workspace install that treats the workspace as a monolith. The conan new workspace that goes in that PR will also contain a super project. So far it seems very promising and allows with a single conan workspace install + cmake --preset commands to have a monolith project that can be open in VS for example and works quite well. The PR is Workspace install with meta-project and monolithic build #17675

@Adnn
Copy link
Contributor Author

Adnn commented Feb 7, 2025

Thank you for this detailed answer, Conan is a stand-out project, moving so fast to address decade old problems in build management.

#17675 seems very promising to address our use case described above. Looking forward to test it on 2.13!

@memsharded
Copy link
Member

Thanks very much for your kind words!

I'll mark this ticket to be closed when #17675 is merged, so this is updated too. Thanks for the feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants