在许多不同的地方,我发现了这一准则:“上游应该支持下游的现代基于目标的设计。”
因此,我正在处理一个基于Autotool的项目,并且能够构建一个合理的ProjectConfig.cmake.in
文件,该文件将由Autoconf解析并用作模板。
get_filename_component(LibUsbgx_CMAKE_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
include(CMakeFindDependencyMacro)
list(APPEND CMAKE_MODULE_PATH ${LibUsbgx_CMAKE_DIR})
list(REMOVE_AT CMAKE_MODULE_PATH -1)
set (prefix @prefix@)
set (exec_prefix @exec_prefix@)
set (libdir @libdir@)
set (includedir @includedir@)
set(LibUsbgx_INCLUDE_DIRS "@includedir@")
if(NOT TARGET LibUsbgx::LibUsbgx)
add_library(LibUsbgx::LibUsbgx SHARED IMPORTED)
set_property(TARGET LibUsbgx::LibUsbgx APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(LibUsbgx::LibUsbgx PROPERTIES
IMPORTED_LOCATION "@libdir@/libusbgx.so"
INTERFACE_INCLUDE_DIRECTORIES "@includedir@")
endif()
unset (prefix)
unset (exec_prefix)
unset (libdir)
unset (includedir)
set(LibUsbgx_LIBRARIES LibUsbgx::LibUsbgx)
两个问题:
@libdir@
扩展到${prefix}/lib
而不是完整路径,因此我不得不进行一些调整才能使它起作用。有办法避免这种黑客入侵吗?@prefix@
会扩展为/usr
,因此路径是绝对的,但是交叉编译要求它们相对于系统路径,因此它无法工作。我该如何解决?谢谢
答案 0 :(得分:0)
受cmake在另一个项目中生成的文件的启发,我以这种方式改进了该文件:
# Compute the installation prefix relative to this file.
get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
if(_IMPORT_PREFIX STREQUAL "/")
set(_IMPORT_PREFIX "")
endif()
set(LibUsbgx_INCLUDE_DIRS "${_IMPORT_PREFIX}/include")
if(NOT TARGET LibUsbgx::LibUsbgx)
add_library(LibUsbgx::LibUsbgx SHARED IMPORTED)
set_property(TARGET LibUsbgx::LibUsbgx APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(LibUsbgx::LibUsbgx PROPERTIES
IMPORTED_LOCATION "${_IMPORT_PREFIX}/lib/libusbgx.so"
INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include")
endif()
我不确定使用autotools
项目执行此操作的正确方法,因为可以通过configure
更改项目来更改libdir,includedir等。