从 qmake 转换为 cmake，如何以相同的方式查找库？

Question

in qmake I can have something like this:

LIBS += -lopengl32 \
    -lglu32 

This will automatically find and link the OpenGL and GLU with my application. How can I do the same in cmake? Is it as simple as:

target_link_libraries(${TARGET_NAME} opengl32 glu32)

If so, how does cmake know where to find these libraries? Is there a way to do this that involves a find_libraries call instead? The above (if it works), would give me anxiety.

Answer 1

Yes, there is a way.

About the sample you provided:

target_link_libraries(${TARGET_NAME} opengl32 glu32)

In this case, when you just list libraries to be linked against, CMake will just pass them to the linker, without any additional work; it is the linker, who must find them.

About the CMake way of including libraries:

However, CMake may help you much much more. Pls take a look at the following code snippet, that represents the preferred way of finding libraries in CMake:

#NOTE: this is a complete & working CMakeLists.txt

project(my_opengl_program)

set(TARGET_NAME ${PROJECT_NAME})
set(TARGET_SOURCES my_opengl_program.cpp my_opengl_program.h)

add_executable(${TARGET_NAME} ${TARGET_SOURCES})

find_package(OpenGL REQUIRED)
target_link_libraries(${TARGET_NAME} OpenGL::GL OpenGL::GLU)

Instead of using find_library directly, use find_package . It will find the libraries you need (by employing find_library internally) and set various helpful variables for you.

Also, most of the packages will also define so-called import libraries, OpenGL::GL and OpenGL::GLU in your case, that can be used for linking. The wonderful thing about linking against the CMake targets is that your executable will inherit all relevant compile/link requirements from the target used for linking. Of course, "import libraries" are also CMake targets:)

Please note that there are NO additional compile/link options, include directories, compile definitions, etc... for your executable. Everything that is necessary is inherited from OpenGL::GL and OpenGL::GLU .

CMake also provides packages formany standard libraries (scroll down to "Find Modules").

About searching for libraries

You can always use find_library directly, and in that case, it is your responsibility to take care of all requirements the library imposes.

Determining the places to search for libraries may be quite complex, and is driven by various CMake variables, as well as parameters passed to find_library . In the simplest case, when no related CMAKE_* variables are changed, and when the find_library is called with basic syntax, like:

find_library(GL_LIB opengl32)
fund_library(GLU_LIB glu32)

Search for openGL32 and glu32 will be controlled by CMAKE_SYSTEM_PREFIX_PATH , CMAKE_SYSTEM_LIBRARY_PATH CMake variables.

In the end, here is the complete documentation for find_library , find_package ,cmake supported libraries (scroll down to "Find Modules"), target_link_libraries

[update]

find_library vs find_package

The question was raised about the difference between find_library and find_package .

Briefly, these two commands do not "compete" but rather "complement" each other. One may think about find_library as a low-level interface for including libraries. In this context, find_package would be a much higher interface, that is easier to use. On the other hand, find_package requires additional support from the library maintainers, or from the CMake directly.

Digging a little deeper into the problem:

Suppose that some library is introduced using find_library (SOME_OTHER_LIB some_other_lib_name) . If the lib was found, the variable SOME_OTHER_LIB will contain the path to the library, which is enough for linking, using target_link_libraries .

But to really use the library, sources need to include SOME_OTHER_LIB specific headers, ie another find_path(...) needs to be introduced, to locate headers, followed by target_include_directories(...) . Also, compile options required by the library also need to be extracted somehow, and introduced using target_compile_options(...)

Of course, if the SOME_OTHER_LIB is used on more than one place, all target_include_directories , target_compile_options , and target_link_libraries must be used all over.

The same process must be repeated for every foreign library that is used.

One can quickly spot the pattern, and this is exactly where find_package becomes handy. All that low-level work is hidden from the end-user (ie developer using CMake), and she/he is presented with a clean and unified interface. The downside is that find_package requires a "kind of driver" that will "drive" the process of including the foreign library. All libraries that are directly supported by CMake may be found oncmake-modules (scroll down to "Find Modules").

The icing on the cake, almost all find modules also create so-called "import libraries" ( OpenGL::GL and OpenGL::GLU in your case) that are cmake targets holding all requirements of the 3rd party library.All those data are inherited by just linking against the import library, making the code much cleaner.

Unfortunately, there are no "enforcements" about the naming of created import libraries (just guidelines), so the only solution is to check the documentation. For OpenGL module, it can be found on FindOpenGL page.