In Visual Studio a "solution" can have multiple projects, further a project can be a dependency of another project.
The reason why it is useful is because Visual Studio builds the dependencies when the project you are building is compiled.
This ensures that the dependency binary you are compiling with is always the most up to date version. Ignoring problems such as work in progress (and not release) code in the custom library, how can this behaviour be achieved in CLion or another Linux development setup/environment?
I understand that the normal workflow is to put the libraries into /usr/lib/ however is there another approach?
Using the structure you laid out in your comment, it could be something like this
project(A)
add_executable(A ${SOURCES_FOR_A})
target_link_libraries(A B C D) # Make A depend on libraries B, C and D
add_library(B STATIC ${SOURCES_FOR_B})
add_library(C STATIC ${SOURCES_FOR_C})
add_library(D STATIC ${SOURCES_FOR_D})
Note that there is no special dependencies between C and D, since static libraries are often nothing more than simple archives of object files. Static libraries are not really linked themselves, you need to provide all static libraries when linking the executable, even if any of them is not used directly by the application.
If the libraries are shared then it's a little different:
project(A)
add_executable(A ${SOURCES_FOR_A})
target_link_libraries(A B C) # Make A depend on libraries B and C
add_library(B SHARED ${SOURCES_FOR_B})
add_library(C SHARED ${SOURCES_FOR_C})
target_link_libraries(C D) # Make C depend on D
add_library(D SHARED ${SOURCES_FOR_D})
Shared libraries are linked and very similar to executable targets. Therefore the target A doesn't need to specify the indirect dependency on D, since it's linked into C.
[Note: The CMake commands shown above might not the exact syntax and arguments needed. Read the documentation for the exact syntax.]