SCons的和/或CMake的：任何方式自动从＆QUOT图;编译＆QUOT中头包括;到＆QUOT;对应的目标文件必须链接＆QUOT;？ [英] SCons and/or CMake: any way to automatically map from "header included during compilation" to "corresponding object file must be linked"?

问题描述

超级简单，完全枯燥的设置：我有一个目录充满.HPP和.cpp文件。有些.cpp文件需要被内置到可执行文件;自然，这些.cpp文件＃包括一些在同一个目录下的.HPP文件，那么其中可能包括其他人，等等，等等的这些大部分文件.HPP的都有相应的.cpp文件，这是说：如果some_application.cpp ＃包括foo.hpp，无论是直接还是及物动词，然后有机会也有需要进行编译和链接到some_application可执行文件Foo.cpp中

Super-simple, totally boring setup: I have a directory full of .hpp and .cpp files. Some of these .cpp files need to be built into executables; naturally, these .cpp files #include some of the .hpp files in the same directory, which may then include others, etc. etc. Most of those .hpp files have corresponding .cpp files, which is to say: if some_application.cpp #includes foo.hpp, either directly or transitively, then chances are there's also a foo.cpp file that needs to be compiled and linked into the some_application executable.

超级简单，但我仍然一无所知什么最好的方式来构建它，无论是在使用SCons或CMake的（均未我有任何的专业知识，用在其他不是在盯着文档的最后一天左右，成为伤心）。我担心的那种解决方案，我的希望的可能实际上是不可能的（或至少严重过于复杂）拉断在大多数构建系统，但即便如此，它会是不错的知道，这样我就可以干脆放弃，并不太挑剔。当然，我希望我是错的，这不会奇怪，因为我是多么的无知关于构建系统（一般来说，大约cmake并Scons的特别）。

Super-simple, but I'm still clueless about what the "best" way to build it is, either in SCons or CMake (neither of which I have any expertise in yet, other than staring at documentation for the last day or so and becoming sad). I fear that the sort of solution I want may actually be impossible (or at least grossly overcomplicated) to pull off in most build systems, but if so, it'd be nice to know that so I can just give up and be less picky. Naturally, I'm hoping I'm wrong, which wouldn't be surprising given how ignorant I am about build systems (in general, and about CMake and SCons in particular).

cmake并使用SCons可以，当然，无论是自动检测some_application.cpp需要重新编译，只要任何这取决于（直接或及物动词）的变化，因为它们可以解析C ++文件不够好头文件挑选出那些依赖关系。 OK，伟大的：我们没有列出每个.cpp-＃包括-.HPP手工的依赖。但是：我们仍然需要决定需要被发送到连接器有什么目标文件的子集，当它的时候实际生成每个可执行

CMake and SCons can, of course, both automatically detect that some_application.cpp needs to be recompiled whenever any of the header files it depends on (either directly or transitively) changes, since they can "parse" C++ files well enough to pick out those dependencies. OK, great: we don't have to list each .cpp-#includes-.hpp dependency by hand. But: we still need to decide what subset of object files need to get sent to the linker when it's time to actually generate each executable.

据我了解，要处理这个问题的一部分两个最简单的方案是：

As I understand it, the two most straightforward alternatives to dealing with that part of the problem are:

• 系统。明确而费力地列举了使用这个目标文件有什么需要使用这些其他目标文件太手工的依赖，即使这些依赖关系的完全镜像到按相应-的.cpp，传递性，包括-的 - 对应-.HPP依赖编译系统的已去搞清楚我们的麻烦。为什么？由于电脑。


• 乙。倾倒在此目录中的所有对象文件到一个单一的图书馆，然后让所有的可执行文件依赖和链接的一个库。这是简单得多，而且据我所知大多数人会做，但它也有点马虎。大部分的可执行文件实际上并不需要的一切在了图书馆，并不会真的需要重建如果只有一个或两个.cpp文件的内容发生变化。是不是这个设置正是那种不必要的计算的所谓的构建系统应该被避免？ （我想，也许他们就不再需要如果库进行动态链接重建，但我只想说，我不喜欢其他原因动态链接库）。

• A. Explicitly and laboriously enumerating the "anything using this object file needs to use these other object files too" dependencies by hand, even though those dependencies are exactly mirrored by the corresponding-.cpp-transitively-includes-the-corresponding-.hpp dependencies that the build system already went to the trouble of figuring out for us. Why? Because computers.
• B. Dumping all the object files in this directory into a single "library", and then having all executables depend on and link in that one library. This is much simpler, and what I understand most people would do, but it's also kinda sloppy. Most of the executables don't actually need everything in that library, and wouldn't actually need to be rebuilt if only the contents of one or two .cpp files changed. Isn't this setting up exactly the kind of unnecessary computation a supposed "build system" should be avoiding? (I suppose maybe they wouldn't need to be rebuilt if the library were dynamically linked, but suffice it to say I dislike dynamically linked libraries for other reasons.)

无论是CMake的或使用SCons可以做得比这在任何远程直接的方式更好？我看到一堆的方式仅限于摆弄自动生成的依赖关系图，但没有通用的方法，这样做的交互（OK，构建系统，你有什么认为依赖关系是不错啊，此基础上，添加下面的依赖关系，并重新思考：？......）。我不是太惊讶了一番。我还没有发现在任构建系统的专用处理机制超级普通情况下链接时相关性应该反映相应的编译时的#include依赖，虽然。我错过了在文档的我（当然有些匆忙的）阅读的东西，或者每个人都只是选项（B），静静地恨自己和/或他们的编译系统？

Can either CMake or SCons do better than this in any remotely straightforward fashion? I see a bunch of limited ways to twiddle the automatically generated dependency graph, but no general-purpose way to do so interactively ("OK, build system, what do you think the dependencies are? Ah. Well, based on that, add the following dependencies and think again: ..."). I'm not too surprised about that. I haven't yet found a special-purpose mechanism in either build system for dealing with the super-common case where link-time dependencies should mirror corresponding compile-time #include dependencies, though. Did I miss something in my (admittedly somewhat cursory) reading of the documentation, or does everyone just go with option (B) and quietly hate themselves and/or their build systems?

推荐答案

您在A点声明）用这个目标文件有什么需要使用这些其他目标文件太的东西，确实需要由手工完成。编译器不自动找到二进制需要目标文件。您可以在链接时明确的列出它们。如果我没有理解你的问题，你不希望有明确的列出一个二进制需要的对象，而是希望构建工具能够自动找到它们。我怀疑有任何建太多，做这样的：使用SCons和CMake的绝对不这样做。

Your statement in point A) "anything using this object file needs to use these other object files too" is something that will indeed need to be done by hand. Compilers dont automatically find object files needed by a binary. You have to explicitly list them at link time. If I understand your question correctly, you dont want to have to explicitly list the objects needed by a binary, but want the build tool to automatically find them. I doubt there is any build too that does this: SCons and Cmake definitely dont do this.

如果你有一个应用程序 some_application.cpp 包括 foo.hpp （或使用这些CPP等标题文件），并且需要将链接 Foo.cpp中对象，然后在SCons的，你需要做这样的事情：

If you have an application some_application.cpp that includes foo.hpp (or other headers used by these cpp files), and subsequently needs to link the foo.cpp object, then in SCons, you will need to do something like this:

env = Environment()
env.Program(target = 'some_application',
            source = ['some_application.cpp', 'foo.cpp'])

这将 仅的当'some_application.cpp'，'foo.hpp'或'Foo.cpp中已经改变了链接。假设G ++，这将有效地转化独立SCons的或CMake的东西像下面。

This will only link when 'some_application.cpp', 'foo.hpp', or 'foo.cpp' have changed. Assuming g++, this will effectively translate to something like the following, independently of SCons or Cmake.

g++ -c foo.cpp -o foo.o
g++ some_application.cpp foo.o -o some_application

您提到您有目录满.HPP和.cpp文件，我会建议你整理这些文件到库中。并不是所有的在一个库中，但在逻辑上组织成更小的，有凝聚力库。然后，您的应用程序/二进制文件将连接所需要的库，从而减少由于不使用的对象重新编译。

You mention you have "a directory full of .hpp and .cpp files", I would suggest you organize those files into libraries. Not all in one library, but logically organize them into smaller, cohesive libraries. Then your applications/binaries would link the libraries they need, thus minimizing recompilations due to not used objects.

这篇关于SCons的和/或CMake的：任何方式自动从＆QUOT图;编译＆QUOT中头包括;到＆QUOT;对应的目标文件必须链接＆QUOT;？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！