CMake中add_library(IMPORTED)与直接链接库的区别及作用问询

Alright, let's break down your questions clearly, like we would in a Stack Overflow thread.

1. Difference between add_library(<tgt> IMPORTED) and direct target_link_libraries(-l <.so|.a>) #

The core difference comes down to CMake's target-based workflow vs raw linker commands. Here's a practical breakdown:

• Target-oriented metadata vs opaque flags: An imported target is a first-class CMake object—you can attach all kinds of metadata to it: header paths, compile options, dependent libraries, and platform-specific paths. Using -l just passes a raw flag to the linker; CLearn has no clue where the library's headers live, if it has dependencies, or how to handle it across different platforms.
• Better maintainability: Imported targets are reusable. If you need to link the same library to multiple executables, you just reference the target name everywhere. With -l, you'd have to repeat the flag (and any associated include paths) every time, making updates like changing the library path a tedious hunt-and-replace.
• Automatic dependency propagation: If your imported library relies on other libraries, you can set INTERFACE_LINK_LIBRARIES on the target. CMake will then automatically link those dependencies to any target that uses your imported library. With -l, you have to manually add every dependent library yourself.
• Cross-platform compatibility: Imported targets let you set platform-specific properties (e.g., different paths for debug/release builds, or Windows .lib files vs Linux .so files). Raw -l flags are platform-dependent and don't play well with CMake's cross-platform logic.
• Seamless header path handling: You can attach header directories to an imported target via INTERFACE_INCLUDE_DIRECTORIES. When another target links to it, CMake automatically adds those include paths to the compiler flags. With -l, you have to manually call include_directories() or target_include_directories() for every target that needs the library's headers.

2. What does add_library(<tgt> [SHARED|STATIC] IMPORTED) do? #

This command creates an imported target in CMake, which represents a pre-compiled library that's already built (not something CMake will compile from source). The SHARED or STATIC keyword tells CMake what type of library it's working with—this is critical for linking logic (e.g., static libraries don't require runtime path setup) and applying the right compiler flags.

You're spot-on about the extra steps and limitations:

• Explicit path configuration is required: Creating the imported target is just the first step. You need to use set_target_properties() to tell CMake where the actual .so/.a file lives, plus any other metadata like header paths. A typical workflow looks like this:

  # 1. Create the imported target
  add_library(foo SHARED IMPORTED)
  # 2. Define its core properties
  set_target_properties(foo PROPERTIES
      IMPORTED_LOCATION "/usr/local/lib/libfoo.so"
      INTERFACE_INCLUDE_DIRECTORIES "/usr/local/include/foo"
  )
  # 3. Link it to your executable
  target_link_libraries(my_executable PRIVATE foo)
  

  That's three commands minimum, as you noted.
• No automatic system header search: CMake doesn't assume the imported library's headers are in system default paths (like /usr/include). You have to explicitly set INTERFACE_INCLUDE_DIRECTORIES if your code needs to include the library's headers. Tools like find_package() (which often creates imported targets under the hood) might handle this for you, but raw imported targets require manual setup.

内容的提问来源于stack exchange，提问作者Spencer Duball