我正在使用 .cpp 和 .h 文件在 Linux OS 中创建一个项目，问题是每次我想要编译和运行项目我必须编译所有内容，否则它不起作用。 例如：
g ++ main.cpp test.cpp test2.cpp test3.cpp test1.h test2.h test3.h -o 主
有没有办法，当我只编辑 main.cpp 时，我不必重新编译所有内容
g ++ main.cpp -o main
答案 0 :(得分：1)
我建议使用makefile来完成这项工作，因为它们在构建依赖项方面非常出色。
https://www.cs.umd.edu/class/fall2002/cmsc214/Tutorial/makefile.html
答案 1 :(得分：0)
如果main.cpp使用来自test * .cpp的代码，则不能只编译main.cpp。您可以使用g++ -c test.cpp将单个文件编译为目标文件，然后使用g++ main.cpp test.o test2.o test3.o -o main链接这些文件。如果您学习使用make，则可以自动执行此过程以仅在需要时重新编译目标文件。
您的源文件中的头文件通常应为#include d，因此您无需在命令行中明确指定它们。
答案 2 :(得分：-1)
增量编译非常标准，是工程上的最佳实践。但是，要实现渐进式编译（至少以理智且可持续的方式实际节省您的时间），您需要使用构建系统来跟踪依赖关系并确定自上次调用之后哪些目标/输入已更改构建系统，它可以自动调用编译器来编译和链接实际需要更新的目标。
对于构建系统的选择，我建议调查Gradle（在开源项目中很受欢迎）或Bazel（谷歌的构建系统最近开源，虽然它不太受欢迎）。从历史上看，Make（以及自动生成Makefile的系统，如Autoconf和CMake）一直是常见的构建系统，尤其是在C ++开发人员中;然而，与更现代的构建系统相比，这些工具的普及程度越来越低，并且使得构建配置更加复杂，并且易于在脚下拍摄（例如，Gradle和Bazel构建了可跨系统移植的配置文件，而Makefile使得无意中依赖于特定于操作系统或特定于编译器的细节使得构建过程变得不可移植相对容易.Make确实有一些非常便携的规则来避免可移植性问题，但在设计makefile时必须非常小心以确保不使用非便携式指令）。有关更全面的C ++构建系统列表，请查看我的C++ resources页面。
至于这些构建系统如何实现增量构建;基本上，他们会将每个* .cpp文件分别编译成自己的* .o文件，并保留* .o文件。然后将每个* .o文件链接在一起以生成最终的构建输出。因此，只重新生成输入比* .o文件更新的* .o文件;类似地，只有那些* .o输入比生成的库或可执行文件更新的库或可执行文件才会被重新创建。简而言之，这些构建系统将进行相当复杂的依赖性分析，以确定哪些文件已更改/要重建哪些目标，并将多次调用g ++（而不仅仅是一次）。这就是为什么我强烈建议使用构建系统自动化它，而不是试图手动执行它。