[SOLVED] Best practice for (CMake) project structure?

Issue

I have implemented a library that, in addition to the actual code, also contains a folder for unit tests and one for examples. Also, this library uses spdlog internally and a proprietary library. Currently my CMake project structure looks like this:

myLib
  |-- CMakeLists.txt
  |-- src/ (The actual lib target)
    |-- CMakeLists.txt
    |-- code etc.
  |-- examples/ 
    |-- CMakeLists.txt
    |-- code etc.
  |-- test/ (unit tests) 
    |-- CMakeLists.txt
    |-- code etc.
  |-- googletest/ (git submodule)
    |-- CMakeLists.txt
    |-- code etc.
  |-- spdlog/ (git submodule)
    |-- CMakeLists.txt
    |-- code etc.
  |-- proprietaryLib/ (git submodule)
    |-- CMakeLists.txt
    |-- code etc.

On its own, this works fine. But if I want to include myLib in an application that also uses googletest and spdlog, for example, it gets messy. Then I can either use the corresponding sources from myLib or I have the modules twice. Both I do not find very nice.

I already thought about making a project only for the lib and a second one for examples/test in which I include the lib as a submodule and link the additional libs (spdlog/proprietaryLib) to it. I could then do the same in the application.

Another approach would be to evaluate in the top CMake if it is the top level project or if it was included via add_subdirectory() and then decide if the subdirectories should be included.

Which solution would you prefer? Are there other/better ones?

Solution

As suggested by fabian I installed gtest/spdlog on my system instead of adding them as submodules and added the following to my top CMakeLists.txt:

find_package(GTest REQUIRED)
find_package(spdlog REQUIRED)

And this to the src/CMakeLists.txt:

target_link_libraries(myLib PRIVATE spdlog::spdlog)

It works. Thanks a lot!

Answered By - Philip Kirchhoff

Answer Checked By - Robin (WPSolving Admin)