CMake 为 VS 项目生成循环依赖，但不生成文件。如何避免？

Posted 2023-02-22

【中文标题】CMake 为 VS 项目生成循环依赖，但不生成文件。如何避免？

【英文标题】：CMake generates circular dependencies for VS project, but not make files. How to avoid?

【发布时间】：2019-08-05 07:53:57

【问题描述】：

这个示例是从我正在从事的一个实际项目中总结出来的；各种 MWE（嗯，不工作会更合适）。

考虑以下项目结构：

.
├── CMakeLists.txt
├── build
├── include
│   └── hello.hpp
└── src
    └── hello.cpp

build 目录用于执行构建并将包含构建工件和中间文件。其余文件的内容将在本题底部给出。

这个想法是install() 构建的库及其标题（以及实际项目中的一些其他内容）。

add_custom_command(
    TARGET $PRJNAME
    POST_BUILD
        COMMAND $CMAKE_COMMAND --build . --target install
    WORKING_DIRECTORY "$CMAKE_BINARY_DIR"
    VERBATIM
)

... 与install() 一起旨在完成此操作，并为生成器Unix Makefiles 和NMake Makefiles 执行此操作，但为Visual Studio 16 2019 创建了循环依赖项（也为Visual Studio 14 2015，但我没有t 测试比这更进一步）。

现在我的直接反应是，这是生成器之间的不一致，但另一方面，除了 make 文件之外的任何项目生成一直是 - IMO - CMake 的弱点之一。

目前我的解决方法是简单地使用NMake Makefiles，但这种方法的缺点是我必须在之前“检测”Visual Studio 并使用vcvarsall.bat、vcvars32.bat 和朋友。但与循环依赖相比，这是一个小麻烦。

如何使用 Visual Studio 项目生成器之一来实现我想要的并避免这种循环依赖？

在 Windows 上，我使用的是 CMake 3.15.1（撰写本文时的最新版本）。

注意：我意识到我可以通过创建自定义命令/目标来实现$CMAKE_COMMAND --build . --target install 的效果，并添加一些file() 命令。但这不会保留它DRY 现在，不是吗？

---

CMakeLists.txt

set(CMAKE_RULE_MESSAGES OFF)
set(CMAKE_VERBOSE_MAKEFILE ON)

cmake_minimum_required(VERSION 3.12 FATAL_ERROR)
set(PRJNAME FOOBAR)

project ($PRJNAME)

set(SOURCE_DIR "src")
set(HEADER_DIR "include")
set(TARGET_DIR "$CMAKE_CURRENT_BINARY_DIR/install-target")
set(PUBLIC_HEADER "$HEADER_DIR/hello.hpp")
set(PROJ_SOURCES "$SOURCE_DIR/hello.cpp")

add_library($PRJNAME SHARED $PROJ_SOURCES)

list(TRANSFORM PUBLIC_HEADER PREPEND "$CMAKE_CURRENT_BINARY_DIR/" OUTPUT_VARIABLE PUBLIC_HEADER_PP)
set_target_properties(
    $PRJNAME
    PROPERTIES
        CXX_STANDARD 11
        CXX_EXTENSIONS OFF
        CXX_STANDARD_REQUIRED ON
        PUBLIC_HEADER "$PUBLIC_HEADER_PP"
        POSITION_INDEPENDENT_CODE 1
)

set(CMAKE_INSTALL_PREFIX $TARGET_DIR)
set(CMAKE_INSTALL_LIBDIR lib)
set(CMAKE_INSTALL_INCLUDEDIR $HEADER_DIR)

install(
    TARGETS $PRJNAME
    ARCHIVE DESTINATION $CMAKE_INSTALL_LIBDIR
    LIBRARY DESTINATION $CMAKE_INSTALL_LIBDIR
    RUNTIME DESTINATION $CMAKE_INSTALL_LIBDIR
    PUBLIC_HEADER DESTINATION $CMAKE_INSTALL_INCLUDEDIR
)

file(MAKE_DIRECTORY "$CMAKE_CURRENT_BINARY_DIR/$HEADER_DIR")
configure_file("$PUBLIC_HEADER" "$CMAKE_CURRENT_BINARY_DIR/$HEADER_DIR/" COPYONLY)
include_directories("$CMAKE_CURRENT_BINARY_DIR/$HEADER_DIR")

add_custom_command(
    TARGET $PRJNAME
    POST_BUILD
        COMMAND $CMAKE_COMMAND --build . --target install
    WORKING_DIRECTORY "$CMAKE_BINARY_DIR"
    VERBATIM
)

set(PKGNAME "foobar-package.zip")

add_custom_command(
    OUTPUT $CMAKE_CURRENT_BINARY_DIR/$PKGNAME
        COMMAND $CMAKE_COMMAND -E tar cv "$CMAKE_CURRENT_BINARY_DIR/$PKGNAME" -- .
    WORKING_DIRECTORY "$TARGET_DIR"
    VERBATIM
)

set_property(DIRECTORY APPEND PROPERTY ADDITIONAL_MAKE_CLEAN_FILES $CMAKE_CURRENT_BINARY_DIR/$PKGNAME)

add_custom_target(
    lib
    DEPENDS $PRJNAME
)

src/hello.cpp

#ifdef _WIN32
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>

BOOL APIENTRY DllMain(HMODULE, DWORD, LPVOID)  return TRUE; 
#endif
#include "hello.hpp"

int hello()  return 42; 

include/hello.cpp

#pragma once

#ifdef _WIN32
#   ifdef FOOBAR_EXPORTS
#       define FOOBAR_API  __declspec(dllexport)
#   else
#       define FOOBAR_API  __declspec(dllimport)
#   endif
#else
#   define FOOBAR_API
#endif

FOOBAR_API int hello();

【参考方案1】：

在我看来，您的用例超出了 CMake 的设计目的。 您正在尝试构建INSTALL 目标，而后者又构建FOOBAR 目标，后者又调用INSTALL 命令。

如果我们通过拆分成两个不同的目标来打破链：FOOBAR 和 FOOBAR_INSTALL 就像这样

add_custom_target($PRJNAME_INSTALL ALL
    $CMAKE_COMMAND --build . --target install
    WORKING_DIRECTORY "$CMAKE_BINARY_DIR"
    VERBATIM
)

我们仍然会通过ALL_BUILD 目标获得循环引用。 因此，如果我们删除 ALL 参数，引用将被破坏，但不会从默认构建命令调用目标，这并不比调用 make 和 make install 更好。

打破依赖关系的适当位置是INSTALL 和其他目标之间。您可以直接调用生成的cmake_install.cmake 脚本，而不是构建INSTALL 目标：

add_custom_command(
    TARGET $PRJNAME
    POST_BUILD
        COMMAND $CMAKE_COMMAND -D CMAKE_INSTALL_CONFIG_NAME=$<CONFIG> -P cmake_install.cmake
    WORKING_DIRECTORY "$CMAKE_BINARY_DIR"
    VERBATIM
)

【讨论】：

非常感谢。这种方法确实打破了依赖循环，我已经调整了我的项目并验证了它的工作原理。