I'd like to enhance the other solutions by providing my CMakeLists.txt file that actually works also in terms of building dependencies.

Solution misusing CMake

cmake_minimum_required(VERSION 2.8)

add_library(lib1 test1.cpp)
add_library(lib2 test2.cpp)
include_directories(${CMAKE_CURRENT_DIR})
add_executable(mainexec main.cpp)
target_link_libraries(mainexec combinedLib)  # Important to place before add_custom_target

set(LIBNAME "combinedLib.lib")

add_custom_command(
    OUTPUT ${LIBNAME}
    COMMAND lib.exe /OUT:${LIBNAME} $<TARGET_FILE:lib1> $<TARGET_FILE:lib2>
    DEPENDS lib1 lib2
    COMMENT "Combining libs..."
)

add_custom_target(combinedLib
    DEPENDS ${LIBNAME}
)

Note that this solution works so far with Visual Studio but I guess it can be made multi-platform compliant. I can imagine that the following version might work for Unix-based platforms:

set(LIBNAME "libCombinedLib.a")

add_custom_command(
    OUTPUT ${LIBNAME}
    COMMAND ar -rcT ${LIBNAME} $<TARGET_FILE:lib1> $<TARGET_FILE:lib2>
    DEPENDS lib1 lib2
    COMMENT "Combining libs..."
)

Note that these solutions somehow misuse CMake as it would complain about a target of type UTILITY (instead of STATIC or SHARED) if you place the target_link_libraries call after the add_custom_target declaration.

CMake target-declaration-compliant solution

To make it CMake compliant, you can replace the `target_link_libraries' call by

target_link_libraries(mainexec ${LIBNAME})
add_dependencies(mainexec combinedLib)

In my case it is not entirely satisfactory because mainexec has to know about combinedLib although it expects all dependencies to be handled by the target_link_libraries call.

Alternative solution with less coupling

Looking a bit further towards imported targets I eventually found a solution that solves my last problem:

cmake_minimum_required(VERSION 2.8)

add_library(lib1 test1.cpp)
add_library(lib2 test2.cpp)
include_directories(${CMAKE_CURRENT_DIR})
add_executable(mainexec main.cpp)

set(LIBNAME "combinedLib.lib")

add_custom_command(
    OUTPUT ${LIBNAME}
    COMMAND lib.exe /OUT:${LIBNAME} $<TARGET_FILE:lib1> $<TARGET_FILE:lib2>
    DEPENDS lib1 lib2
    COMMENT "Combining libs..."
)

add_custom_target(combinedLibGenerator
    DEPENDS ${LIBNAME}
)

add_library(combinedLib STATIC IMPORTED)
set_property(TARGET combinedLib PROPERTY IMPORTED_LOCATION ${LIBNAME})
add_dependencies(combinedLib combinedLibGenerator)

target_link_libraries(mainexec combinedLib)

If you intend to modularize the whole add GLOBAL after STATIC IMPORTED to make the imported target globally visible.

Portable CMake solution

With the current CMake versions CMake provides full support for transitive dependencies and interface libraries. An interface library can then "link" against other libraries and this interface library can, in turn, be "linked" against. Why quotation marks? While this works good, this actually doesn't create a physical, combined library but rather creates a kind of an alias to the set of "sub-libs". Still this was the solution we eventually needed, which is why I wanted to add it here.

add_library(combinedLib INTERFACE)
target_link_libraries(combinedLib INTERFACE lib1 lib2)

target_link_libraries(mainexec combinedLib)

That's it!

Mind if I ask how come? As in are your customers asking you for that? Or are you doing it more as a learning exercise?

```Additionally, I want for the user of my library to not have to install OpenCV 4 on their system (but do not mind if the user has to do simple installs using apt-get install)```

In my experience customers like installers and package managers so using a tool like CPack with DEB/RPM generators will automatically create and orchestrate the required dependencies for pretty much most targeted platforms.

To answer your question more directly I'm not sure that it is possible in the generic sense. This is likely for two reasons, dependency hell and license agreements. Below is my limited knowledge someone can correct me if I am completely spreading FUD or wrong.

Sure your library may depend on static libraries. But the dependencies that you are specifying will likely have dependencies on shared libs. And your dependencies dependencies will likely have dependencies on shared libs, and we can follow the rabbit whole down into dependency hell.

Now assuming that we have a simple project and dependency hell is not an issue and everything is statically linked all the way through. Making the decision to compile a library static or shared has dramatic implications on your customers because of licensing. If you have any code that has hard FOSS requirements it means that your library will plainly not be used in business or probably the general sense if it is STATIC because the license agreements on things like LGPLv3 and LGPLv2 make it near impossible to incorporate into a customers environment. Now you need to manage and audit closely all of the ENTIRE licenses used by both you, your dependencies, and your dependencies dependencies.

As a learning excercise on how libraries are put together though I think it sounds like a really fun project!