CMake 可以识别具有另一个名称(CMakeLists_nightly.txt)的 CMakeLists.txt 吗?

发布于 2024-12-02 07:40:20 字数 325 浏览 0 评论 0原文

我想要创建更具体命名的 CMakeLists.txt 文件,例如“CMakeLists_nightly.txt”、“CMakeLists_weekly.txt”等。我想这样做的原因是为了减少项目中文件夹层次结构的混乱。我可以轻松地将每个文件放在自己的文件夹中,并使用上面显示的后缀,但我不想这样做。

我可以告诉 cmake 使用另一个名称获取 CMakeLists.txt 文件吗?我之前在另一个论坛(http://www.cmake.org/pipermail/cmake/2007-August/016036.html)上看到过这个问题,但那是在 2007 年,答案是否定的。当前版本的 CMake 是否提供此功能?

I am wanting to create CMakeLists.txt files that are more specifically named such as "CMakeLists_nightly.txt", "CMakeLists_weekly.txt" and so forth. The reason I want to do this is to cut down on the folder hierarchy clutter of my project. I could easily put each of these files in their own folder with the postfix I showed above but I do not want to do this.

Can I tell cmake to take a CMakeLists.txt file by another name? I have seen this question asked before on another forum (http://www.cmake.org/pipermail/cmake/2007-August/016036.html) but it was back in 2007 and the answer was no. Does the current version of CMake provide this capability?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

木森分化 2024-12-09 07:40:20

不是真的,但您可以通过将 CMakeLists.txt 放在单独的目录中来模拟这一点,例如 continous/CMakeLists.txtnightly/CMakeLists.txt 。使用 INCLUDE 包含每个构建配置的适当脚本。

考虑一下这是否真的是正确的方法 - 完全分离夜间脚本和连续脚本是一个非常糟糕的主意,因为这将导致重复和非常容易出现错误的构建设置。

Not really, but you can emulate this by putting CMakeLists.txt in separate directories, e.g. continous/CMakeLists.txt and nightly/CMakeLists.txt. Use INCLUDE to include the appropriate scripts for each of the build configs.

Consider if this really is the right approach - completely separating the nightly and continuous script is a really bad idea as that will lead to duplication and a very bug prone build setup.

乖乖兔^ω^ 2024-12-09 07:40:20

答案,当我阅读 larsmoa 的答案并思考了一会儿时,我想到了这个答案:(

这并不完全是关于 CMakeLists.txt 的不同名称的问题的答案,但是相反,“如何在同一目录中拥有两个不同的 CMake 配置文件”)

您可以避免创建多个目录并在其中存储 CMakeLists.txt (如果您希望脚本成为所有内容的父级,这也可能是有问题的)。我的想法是,您可以有两个“包含”cmake 文件,名称任意。然后在 CMakeLists.txt 中,您可能有一个 set(CACHE),它控制实际应包含的包含脚本。

通过此设置,您可以拥有两个构建目录:一个配置了选项的一个值,另一个配置了另一个值。根据您在哪个构建目录中进行构建,将使用相应的构建定义。

它可能看起来像这样:

CMakeLists.txt:

set(
    MY_BUILD_KIND BUILD_A CACHE STRING 
    "Select build kind: BUILD_A or BUILD_B"
)

if ( MY_BUILD_KIND strequal "BUILD_A" )
    include(build_a.cmake)
elseif (MY_BUILD_KIND strequal "BUILD_B")
    include(build_b.cmake)
else ()
    message ( FATAL_ERROR "Unknown build kind: ${MY_BUILD_KIND}" )
endif () 

Background (为什么我需要它?):我猜我的情况有点奇怪。我有一个 C++ 项目,其中的不同部分使用两个不同的编译器。其中有一部分需要他们每个人来建造。所以目录结构是这样的:

  • Projects
    • 编译器A项目
    • 编译器B项目
    • 常见项目

此处“CommonProjects”作为“CompilerAProjects”的一部分包含在内,也作为“CompilerBProjects”的一部分包含在内。现在我们尝试集成 cmake,我在想,我们如何保持结构,但使用 CMake 进行构建。如果我将 CMakeLists.txt 放在根目录中,那么我不明白如何区分两个编译器。如果我没有根项目,那么就不清楚如何引用“兄弟”项目。所以我想到了,我可以根据当前的编译器包含子目录。然后我决定,实际上没有必要,编译器是驱动因素,我们可以使用 set(CACHE) 代替。而且我们不限于选择哪个子目录,还可以包含“.cmake”文件。

Answer, which came into my mind, while I was reading an answer from larsmoa and thinking about it little bit longer:

(this is not exactly the answer to the question about different name for CMakeLists.txt, but rather, to "how to have two different CMake configuraiton files in the same directory")

You can avoid creating multiple directories and storing there CMakeLists.txt (it may also be problematic, if you want your script to be the parent of everything). My Idea is, that you can have two "include" cmake files with any names you like. And then in CMakeLists.txt you may have an set(CACHE), which controlls, which include-script should be actually included.

With this setup you can have two build directories: one configured with one value of the option, and another - with another. Depending on that, in which build-directory you do the build, corresponding build definition will be used.

It can look something like this:

CMakeLists.txt:

set(
    MY_BUILD_KIND BUILD_A CACHE STRING 
    "Select build kind: BUILD_A or BUILD_B"
)

if ( MY_BUILD_KIND strequal "BUILD_A" )
    include(build_a.cmake)
elseif (MY_BUILD_KIND strequal "BUILD_B")
    include(build_b.cmake)
else ()
    message ( FATAL_ERROR "Unknown build kind: ${MY_BUILD_KIND}" )
endif () 

Background (why do I need it?): My situation is kind of exotic, I guess. I have a C++ project, different parts of which use two different compilers. And there is a part of it, which needs to be built by each of them. So the directory structure is like this:

  • Projects
    • CompilerAProjects
    • CompilerBProjects
    • CommonProjects

Here "CommonProjects" are included as Part of "CompilerAProjects" and also as part of "CompilerBProjects". Now we try to integrate cmake and I was thinking, how can we keep the structure, but do the build with CMake. If I put CMakeLists.txt in the root directory, then I don't understand, how to differentiate between two compilers. And if I don't have the root project, then it is not clear, how to refer to "sibling" project. So I came to the idea, that I can included sub-directories basing on the current compiler. And then I decided, that actually it is not necessary, that compiler is the driving factor, we can use set(CACHE) instead. And we are not restricted to select, which sub-directory we select, but can also include ".cmake" files.

还不是爱你 2024-12-09 07:40:20

不可以。CMake 只能识别名为“CMakeLists.txt”的 CMakeLists.txt 文件。

请自行查看:它在 CMake 二进制文件的源代码中的多个位置进行了硬编码(包括 Source/cmake.cxxSource/cmMakefile.cxx)以及 CMake 内置模块脚本(包括 FetchContent)。


我想提出一个框架挑战:您可以为调用项目配置的人定义选项变量以使用(他们可以使用 -DcacheVariables 在 <一个href="https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html#configure-preset" rel="nofollow noreferrer">配置预设)。您的项目配置可以读取这些变量 并根据这些选项变量做任何它想要改变的事情。前任。请参阅if命令条件生成器表达式。您还可以使用 option< 为这些选项变量设置默认值和文档字符串/code>设置(... CACHE ...)

No. CMake only recognizes CMakeLists.txt files named "CMakeLists.txt"

See for yourself: It's hardcoded in several places in the CMake binary's source code (including cmake::DoPreConfigureChecks in Source/cmake.cxx and cmMakefile::ConfigureSubDirectory in Source/cmMakefile.cxx) and also in the CMake builtin module scripts (including FetchContent).


I'd like to pose a frame challenge: You can define option variables for the person invoking configuration of the project to use (they can define cache variables via commandline using -D, or cacheVariables in a configure preset). Your project configuration can read those variables and do whatever it wants to change itself based on those option variables. Ex. See the if command and conditional generator expressions. You can also set default values and docstrings for those option variables using option or set(... CACHE ...).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文