[question] Conan 2 with legacy mono repo

[mattangus]

What is your question?

I would like to understand some of the best practices around adding conan to existing production code. In particular to a mono repo.

I have an SDK that is split into multiple libraries. The folder structure looks something like this:

src/
   CMakeLists.txt
   libA/
      include/libA
          libA.h
      lib/
          libA.cxx
      CMakeLists.txt
   libB/
      include/libB
          libB.h
      lib/
          libB.cxx
      CMakeLists.txt

Each call to add_library is done inside each respective CMakeLists.txt. Each library is included in the main project via add_subdirectory. Unfortunately changing the structure of this code is not an option at the moment. Each library would also need to be published without the source as it's proprietary and the consumers of this should not have access to the implementation, only headers and libs. also libB depends on libA.

My initial thought is that alongside each CMakeLists.txt there would be a conanfile.py. It's not clear how conan cli would be invoked on each sub library. Then there are the dependencies, is it possible that they can be shared between each of these sub libraries?

The goal would be for a downstream application to have libB/version as a requirement in their conanfile.py, and it would pull libA and libB and make it available to the user.

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @mattangus

Thanks for your question.

I think it depends on what problem you are trying to solve.

If you have external dependencies outside of the mono repo, like third parties or even your organization packages, that you want to use in this project, then a single conanfile.py in the root of the project, with all the find_package() in the root src/CMakeLists.txt will be a simple and recommended approach.

Now, if what you are trying to achieve is the publication of packages built from this mono-repo, as independent (and independently versioned) Conan packages, then probably some pragmatic approach could be:

• I guess that you want a monolithic build, not a Conan per-package one, so that leaves the build() method out of the equation, and using the conan export-pkg command to package pre-compiled binaries could be simple and effective
• You put a conanfile.py in each subfolder, implement the package() method and the package_info() method to copy the headers and the pre-compiled libs (they were built in the mono-repo build)
• You have a small script that iterates your folders, calling conan export-pkg in each of them to create the packages, then conan upload them to your server.

If you'd like to have a mono-repo and at the same time, model the dependencies accross subfolders as Conan packages, that is way more challenging. The conan editables might help a little, but basically mono-repo development and package-based development are completely opposite paradigms, and it is very complicated to have both of them at the same time. We will continue working soon in the workspace feature, which intends to improve over this model, but still there are inherent build system limitations, even for CMake despite being the most powerful, that disallow working simultaneously under a package-based flow and a mono-repo flow.

Please let me know if this helps.

[mattangus]

Yes I think that answers it! The main piece that I was missing is populating package() and package_info(). I was trying to, as you say, mix the paradigms. Ideally we will eventually split each library into it's own repo, but this will be a helpful step along the way. thank you!

I will try this over the next few days and see if run into any roadblocks. Feel free to close this now otherwise I may come back with follow ups.

[memsharded]

Sounds good, often it is better to be pragmatic than too purist, and trying to go too far in the integration can be counter productive. So the conan export-pkg might be the pragmatic approach at the moment.

Sure, I'll close it by now if it doesn't need attention from us, but feel free to re-open or create new tickets as necessary. Thanks for the feedback!