从 cmake 3.9 开始，引入了以下generator expression：
$<TARGET_BUNDLE_DIR:tgt>
文档指出：
bundle 目录（my.app、my.framework 或 my.bundle）的完整路径，其中 tgt 是目标的名称。
如果使用 cmake
我尝试了以下方法：
include(BundleUtilities)
get_dotapp_dir($<TARGET_FILE:my_target> DOTAPP_DIR)
不幸的是，它不起作用。 get_dotapp_dir 的文档说：
在给出可执行文件的完整路径的情况下，返回名称以“.app”结尾的最近父目录。如果没有这样的父目录，则只需返回包含可执行文件的目录。
并且包含可执行文件的目录正是我从中得到的，即使父目录.app 确实存在。
【问题讨论】：
不幸的是，$<TARGET_FILE:my_target> 是一个生成器表达式。根据文档，它是在构建时评估的（而不是在 CMake 生成时）。请参阅相关文档（重点是我的）：
生成器表达式在构建系统生成期间进行评估以 生成特定于每个构建配置的信息。
在许多目标的上下文中允许生成器表达式 属性，例如 LINK_LIBRARIES、INCLUDE_DIRECTORIES、 COMPILE_DEFINITIONS 等。它们也可以在使用时使用 填充这些属性的命令，例如 target_link_libraries(), target_include_directories(), target_compile_definitions() 等。
换句话说，您不能使用$<TARGET_FILE:my_target> 作为get_dotapp_dir 的参数。您必须传递一个包含可执行文件完整路径的变量。
从 CMake 3 开始，如果没有这个生成器表达式，就无法检索生成目标的完整路径。请参阅CMP0026 了解更多信息。
因此，只要您将此策略设置为其默认值，您将无法计算可执行文件或父捆绑包的完整路径。
You are not the first 试图解决这个问题。但根据“如何处理此捆绑路径”，您可以尝试以下解决方案：
OLD，并使用 LOCATION 属性获取可执行文件的路径，并将此路径提供给 get_dotapp_dir 以检索相应的包路径。此解决方案绝对不可移植，将来可能会停止工作，不建议使用...目前，我们在一些项目中使用这样的东西：
add_custom_command(TARGET MyTarget POST_BUILD
COMMAND ${PYTHON_EXECUTABLE} -u MakeRelease.py $<TARGET_FILE:MyTarget>
)
不幸的是，目前在配置时没有干净的方法来检索包路径...
【讨论】：
LOCATION 绑定到.app 目录时，目标是一个包？我实际上并没有尝试，因为我猜它返回了包中可执行文件的路径。
add_executable被调用时，目标被标记为MACOSX_BUNDLE。我知道它是在哪里构建的，我要问的是此类目标的LOCATION 属性是否包含可执行文件的路径或捆绑包的路径，因为$<TARGET_FILE:my_target> 包含可执行文件之一。
LOCATION 和 get_dotapp_dir这一事实。它将帮助未来的读者。谢谢。