gmake 的替代品?

发布于 2024-09-30 20:03:13 字数 194 浏览 5 评论 0原文

我有一个 C++ 程序文件,其中有两个函数。如果我单独更改第一个函数,为什么必须重新编译它们? 是否有任何构建系统可以单独重新编译第一个并将其放回到同一个目标文件中? 这可能吗?一个函数的指令不应该依赖于另一个函数,对吧? 由于gmake重新编译整个文件,需要花费很多时间,这不能避免吗?将第二个函数放在单独的文件中并不是一个好主意,因为它涉及创建不必要的不​​需要的文件。

I have a c++ program file with two functions in it. If I change the first function alone, why should both of them have to be recompiled?
Is there any build system which recompiles the first one alone and put it back in the same object file?
Is this possible? The instructions of one function shouldn't depend on other right?
Since gmake recompiles the whole file, it takes a lot of time, cant this be avoided? Putting the second function in a separate file is not a good idea, as it involves creation of unwanted files which is not necessary.

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

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

发布评论

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

评论(6

提笔落墨 2024-10-07 20:03:13

如果第二个函数很长或需要更多时间来编译,请将其放在单独的文件中。这就是人们分离源文件的原因。据我所知,它必须编译整个文件,因为源代码的微小变化将导致输出文件的重大变化,因为函数不会相互链接。

If the second function is quite long or requires more time to compile, place it in a separate file. That is why people separate source files. From what I know, it has to compile the whole file, as a small change in the source will result in a major change in the output file, as the functions would not link to each other.

不奢求什么 2024-10-07 20:03:13

我怀疑使用任何编程语言都可能只编译源文件的一部分。编译是在每个文件的基础上完成的。

I doubt that compiling only part of a source file is ever possible, using any programming language. Compilations are done on a per-file basis.

邮友 2024-10-07 20:03:13

在大多数情况下,用于确定给定源文件的哪些语义部分已更改并因此需要重新编译的分析可能会超过编译本身的成本。

构建系统通过分析源文件之间的依赖关系获得巨大胜利,因为文件 I/O(特别是包含文件)的成本占总体编译成本的很大一部分。一旦您决定重新编译给定的源文件,您可能只能通过忽略文件中未更改的部分来实现微小的加速,即使计算这些部分的成本为零。

The analysis to decide which semantic parts of a given source file have changed and thus need recompiling would likely outweigh the cost of the compilation itself in most cases.

Build systems get big wins by analyzing the dependencies between source files because the cost of file I/O (particularly for include files) is a large part of the overall compilation cost. Once you've decided to recompile a given source file, you would likely only achieve a tiny speedup by ignoring unchanged parts of the file, even if there were zero cost to computing which parts those were.

残花月 2024-10-07 20:03:13

我所知道的所有 C++ 构建系统都在翻译单元(文件)级别工作,而不是在函数级别工作。尽管从理论上讲这应该是可能的,但当您考虑预处理器时,它会很复杂,例如,

#define ANSWER 42

void foo()
{
#undef ANSWER
#define ANSWER 41
}

int bar()
{
    return ANSWER;
}

虽然这是一个糟糕的代码,但任何符合标准的编译器/构建系统都应该支持它。正如您所看到的,更改 foo (重新定义 ANSWER)可能会影响 bar

All build systems for C++ that I know work on translation unit (file) level, not on function level. Although in theory it should be possible it is complicated when you consider the preprocessor, e.g.

#define ANSWER 42

void foo()
{
#undef ANSWER
#define ANSWER 41
}

int bar()
{
    return ANSWER;
}

Although this is a terrible code any standard compliant compiler/build system should support it. And as you can see changing foo (redefining ANSWER) can affect bar.

不必在意 2024-10-07 20:03:13

将第二个函数放在单独的文件中一个好主意,并且如果您想避免这个“问题”,必要的。如果您的函数太大,以至于重新编译一个文件所花费的时间很明显,那么该文件可能太大,无论如何都应该分解。

Putting the second function in a separate file is a good idea, and is necessary if you want to avoid this "problem". If your functions are so large that the time spent recompiling one file is noticeable, then the file is probably too big and should be broken up anyway.

睫毛上残留的泪 2024-10-07 20:03:13

问题不在于 gmake,而在于编译器。如果更改一个函数,您可能别无选择,只能重新编译其他函数。例如:

  • 如果函数a调用函数b,并且您更改函数b,则需要确保a > 仍然可以正确调用 b,以防 b 的签名发生变化。
  • 如果函数 b 位于内存中的 ac 之间,并且现在 b 增长以致不再适合,您可能必须移动 ac,这还涉及重新编译以生成正确的偏移量。
  • 如果 b 不再位于同一位置,则需要编译其调用者 a 以指向正确的函数。

可能有更多更好的情况需要这样做。

The issue isn't gmake, it's the compiler. If you change one function, you may have no choice but to recompile others. For instance:

  • if function a calls function b, and you change function b, you need to ensure that the a still calls b correctly, in case b's signature changed.
  • if function b is between a and c in the memory, and now b grows so that it no longer fits, you may have to move either a or c, which also involves recompiling to generate correct offsets.
  • If b is no longer in the same place, you need to compile its caller, a to point to the right function.

There are probably more and better cases where this is necessary.

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