本文介绍了$< TARGET_BUNDLE_DIR:tgt>等同于cmake的生成器< 3.9的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

从cmake 3.9开始,以下生成器表达式:

Since cmake 3.9 the following generator expression has been introduced:

$<TARGET_BUNDLE_DIR:tgt>

文档说明:

如果使用cmake<如何获得相同的结果(bundle目录的路径). 3.9?

How can one obtain the same result (path to the bundle directory) if using cmake < 3.9?

我尝试了以下操作:

include(BundleUtilities)
get_dotapp_dir($<TARGET_FILE:my_target> DOTAPP_DIR)

不幸的是,它不起作用. get_dotapp_dir的文档说:

Unfortunately it doesn't work. The documentation for get_dotapp_dir says:

包含可执行文件的目录正是我从中得到的,即使实际上存在父目录.app.

And the dir containing the executable is exactly what I'm getting out of it, even if a parent .app dir actually exists.

推荐答案

不幸的是,$<TARGET_FILE:my_target>是生成器表达式.根据文档,它是在构建时(而不是在CMake生成时)进行评估的.请参阅相关文档(重点是我的文档):

Unfortunately, $<TARGET_FILE:my_target> is a generator expression. According to the documentation, it is evaluated at build time (not at CMake generation time). See the related doc (emphasis is mine):

在许多目标的上下文中允许生成器表达式 属性,例如LINK_LIBRARIES,INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS等.在使用时也可以使用它们 用于填充这些属性的命令,例如 target_link_libraries(),target_include_directories(), target_compile_definitions()等.

Generator expressions are allowed in the context of many target properties, such as LINK_LIBRARIES, INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS and others. They may also be used when using commands to populate those properties, such as target_link_libraries(), target_include_directories(), target_compile_definitions() and others.

换句话说,不能将$<TARGET_FILE:my_target>用作get_dotapp_dir的参数.您必须传递一个包含可执行文件完整路径的变量.

In other words, you cannot use $<TARGET_FILE:my_target> as argument to get_dotapp_dir. You have to pass a variable containing the full path of your executable.

自CMake 3起,没有此生成器表达式就无法检索生成目标的完整路径.有关更多信息,请参见 CMP0026 .

Since CMake 3, the full path of generated target is impossible to retrieve without this generator expression. See CMP0026 for more info.

只要将此策略设置为默认值,就无法计算可执行文件或父捆绑包的完整路径.

So as long as you keep this Policy set to its default value, you will not be able to compute the full path to your executable or the parent bundle.

您不是第一个尝试解决此问题的人.但是,根据与此包路径有何关系",您可以尝试以下解决方案:

You are not the first trying to solve this issue. But depending on "what to do with this bundle path", you may try the following solutions:

  1. 将CMP0026设置为OLD,并使用LOCATION属性获取可执行文件的路径,并将此路径提供给get_dotapp_dir以检索相应的分发包路径.该解决方案绝对不是便携式的,将来可能会停止工作,不建议使用...
  2. 如果您需要从自定义命令或自定义目标访问绑定路径(在构建时),则可以使用脚本(python,php,bash,perl等)来计算从中进行绑定的路径可执行文件的路径.
  1. Set CMP0026 to OLD, and use LOCATION property to get the path to your executable, and the give this path to get_dotapp_dir to retrieve the corresponding bundle path. This solution is definitely not portable, may stop to work in the future, and is not advised...
  2. If you need to access to your bundle path from a custom command or a custom target (at build time), you may use a script (python, php, bash, perl, etc.) to compute the path to bundle from the path to executable.

当前,我们在某些项目中使用以下内容:

Currently, we use something like this in some project:

add_custom_command(TARGET MyTarget POST_BUILD
    COMMAND ${PYTHON_EXECUTABLE} -u MakeRelease.py $<TARGET_FILE:MyTarget>
)

不幸的是,目前还没有干净的方法可以在配置时检索捆绑包路径...

Unfortunately, there is no clean way to retrieve the bundle path at configuration time at the moment...

这篇关于$&lt; TARGET_BUNDLE_DIR:tgt&gt;等同于cmake的生成器&lt; 3.9的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

10-29 23:48