作者:qinsg688_377 | 来源:互联网 | 2023-08-30 07:03
篇首语:本文由编程笔记#小编为大家整理,主要介绍了在Eclipse中引用外部文件:在项目属性中虚拟链接文件与构建设置?相关的知识,希望对你有一定的参考价值。
Web上有关于CDT Eclipse中使用外部文件资源的主题的信息:C / C ++和H文件位于文件系统的其他位置。所有描述的方法都有两种方法:
- 在项目空间内创建虚拟链接文件,这些文件指向实际文件的位置而不复制它们
- 在Project-> Properties-> C / C ++ general-> Paths and Symbols and related Project-> Properties-> C / C ++ Build(链接文件夹和包含)中添加外部引用资源的位置
我不确定第一种方法是否总是足够而不添加第二种方法,但似乎第二种方法在没有第一种情况下很好地构建。
我的问题是关于两者的比较。这些方法是否应该被类似地使用,或者在某些情况下每个方法都是首选的?
每种方法都自给自足而不应用其他方法吗?
这个论坛帖子https://www.eclipse.org/forums/index.php/t/1087314/建议,对于包含文件,第一种方法可能甚至不够,因为Build Settings仍应更新(第二种方法)以包含链接的H文件......那么第一种方法可能是无关紧要的?
答案
如果要编辑外部定位文件作为项目工作的一部分,通常使用第一种方法,如果它们只是您在不修改的情况下使用的依赖项,则通常使用第二种方法。
在技术层面上,不同之处在于,使用第一种方法,文件将成为项目模型的一部分,因此,例如在Open Resource中显示为候选者,而在第二种方法中他们不会。另一个区别是,对于第一种方法,文件是独立索引的,而使用第二种方法,文件只是由于被项目中的文件包含而被编入索引(因此,例如,这些目录中的.cpp
文件通常不会被编入索引)第二种方法)。
更新:评论中的问题答案
第一种方法在所有情况下是否足够,而不更新路径和符号属性?
不,如果链接目录中存在头文件,这些头文件包含在项目中的文件中,使用的包含路径与当前目录不相关(因此不只是同一目录中的#include "foo.h"
,子目录中的#include "../foo.h"
等,但是在其他目录中的#include
),你仍然想在Paths和Symbols中指定那些包含路径。
CDT的索引器确实有一个“允许启发式解析包含”选项(在Preferences - > C / C ++ - > Indexer中指定)可能允许您避免添加路径和符号的路径,但请注意(1)这会影响索引器只是,而不是构建(如果你使用自己的makefile进行构建可能会很好),以及(2)因为它是启发式的,它并不完美,例如如果你在不同的目录中有相同名称的标题,它可能会混淆。为了获得最佳效果,我建议取消选中“允许启发式解析包含”,并始终明确指定包含路径。
如果引用的文件无需修改即可使用第二种方法本身就足够了吗?
我不明白为什么不。