在Web 上以及这里都有关于在 CDT Eclipse 中使用外部文件资源相关的主题的信息：位于文件系统中其他地方的 C/C++ 和 H 文件。所有描述的方法都沿着两个方法运行：
- 在项目空间内创建指向的虚拟链接文件 实际文件的位置而不复制它们
- 在项目->属性->C/C++ 常规->路径和符号及相关项目->属性-> C/C++ 生成(链接文件夹和包含)
我不确定第 1 种方法在不添加第 2 种方法的情况下是否总是足够，但似乎第 2 种方法在没有第 1 种方法的情况下构建得很好。
我的问题是关于两者的比较。这些方法是否打算类似地使用，或者在某些情况下每种方法都是首选？
每种方法是否在不应用其他方法的情况下都自给自足？
此论坛主题 https://www.eclipse.org/forums/index.php/t/1087314/建议对于包含文件，第一种方法甚至可能还不够，因为仍应更新构建设置(第二种方法)以包含链接的 H 文件......那么可能是第一种方法无关紧要？
如果要编辑位于外部的文件作为项目工作的一部分，则通常使用第一种方法，如果它们只是您不使用修改的依赖项，则使用第二种方法。
在技术层面上，区别在于，使用第一种方法，文件将成为项目模型的一部分，因此例如在开放资源中显示为候选者，而使用第二种方法则不会。另一个区别是，使用第一种方法，文件是独立索引的，而使用第二种方法，文件仅通过包含在项目中的文件来索引(例如 这些目录中.cpp文件通常根本不会使用第二种方法进行索引)。
更新：对评论中问题的回答
第一种方法是否在所有情况下都足够，而无需更新路径和符号属性？
否，如果链接目录中的头文件被项目中的文件包含，而包含路径与当前目录无关(因此不仅#include "foo.h"在同一目录中，#include "../foo.h"子目录中等，#include <bar/foo.h>在某个其他目录中)，则仍希望在路径和符号中指定这些包含路径。
CDT 的索引器确实有一个"允许启发式解析包含"选项(在首选项 -> C/C++ -> 索引器中指定)，该选项可能允许你避免将路径添加到路径和符号，但请注意 (1) 这仅影响索引器，而不影响生成(如果使用自己的生成文件进行生成，这可能没问题)，以及 (2) 因为它是启发式的， 它并不完美，例如，如果您在不同的目录中有同名的标头，则可能会感到困惑。为了获得最佳准确性，我建议取消选中"允许启发式解析包含"，并始终显式指定包含路径。
此外，如果引用的文件按原样使用而不进行修改，第二种方法本身是否足够？
我不明白为什么不。