How to avoid the root's CMakeLists.txt?

[alexisfrjp]

Thanks for your example project, that helped me a lot in the CMake chaos.
I have the same hierarchy and I was lost between the use of all the functions, especially with find_package().

How can we avoid the root's CMakeLists.txt that glues the app and the libs together?

Because I have several apps that use different libraries, there is a problem.
It would be nice to be able to compile the app directly inside the app folder.

1. Either we link the lib in the app's CMakeLists.txt using add_subdirectories(../libs) but that's considered anti-pattern.
   1.1. Pro: At the app compilation, the libs are compiled too.
2. We somehow export the libs without installing them and import them in the app CMakeLists.txt with find_package()/find_libraries()
   2.1. It seems the find_*() don't trigger the compilation of those libraries and they need to be installed in the OS, what I don't want to do.

Any thought on that?

[rvarago]

Hi @alexisfrjp, thanks for your comment. I am glad to know the template has been of some help.

Mm, you have applications and libraries that you want to link against each other, but they are not in the same location (e.g. repository). Would that be correct?

If that's the case, then maybe a package manager (such as Vcpkg, conan, etc) would be an option to consider.

Alternatively, for some use cases, CMake's FetchContent, or even git-submodules, may be good enough.

Please, let me know if that helps. If not, then it would be great if you could give us a little bit more of context, perhaps an example? I'd be happy to help you out.

Best.

[alexisfrjp]

That was very helpful :) I'd like to avoid using one more dependency tool.

Mm, you have applications and libraries that you want to link against each other, but they are not in the same location (e.g. repository). Would that be correct?

Exactly, even if it's in the same repository just not using a top-level CMakeLists.txt because that will become quickly a mess if there are several applications (targets).

Maybe what I wanna do doesn't make sense taking in account the CMake workflow.

[rvarago]

Oh, I see.

Without a top-level CMakeLists txt, I believe we would then need some tool (e.g. the ones I mentioned in the previous comment) that fetches the targets from somewhere and makes them available.

Or rather, I cannot think of any other way right now :/.

Perhaps having the top-level CMakeLists.txt, and keeping it as simple as possible (e.g. only grouping and delegating to sub-directories) would be the easiest path forward.

But as you said, it can become messy and therefore it requires discipline to ensure that no "big ball of mud" will be formed (e.g. abuse of macros and commands that affect the global scope).

I will put some more efforts on the matter and come back to you as soon as I have a more satisfying answer :).

Best.

[alexisfrjp]

@rvarago Thanks for you answer and sorry for my late answer, I had more urgent work.

I see, the top level CMakeLists.txt forces me to compile everything. I guess I can have different CMakeLists.txt.

Basically I want a monorepo with several libraries that might be dependent to other(s).

.
+-- CMakeLists.txt
|
+-- app_1
|   +-- CMakeLists.txt
+-- app_2
|   +-- CMakeLists.txt
|
+-- libs
|   +-- libA
|       +-- CMakeLists.txt
|   +-- libB
|       +-- CMakeLists.txt
|   +-- libC
|       +-- CMakeLists.txt

I'd like to be able to compile each libX to generate .a/.so file and also being able to compile the app_* linking the libraries statically/dynamically or in_source.

For example:

• Compiling app_1 as one final object with the libs' source for debugging purposes for the dev team.
• Compiling app_1 only, linking static/shared libraries for production.

Also:

• libC is the final library to go production as .a/.so file. It's dependent on libA and libB but I'd like to compile the libC as if libA and libB were part of the libC codebase.

If you have any recommendation, it'd be very appreciated :)