是否可以指定远程预处理器服务器的C / C ++包含路径?
这里的重点是头文件只有一个中央位置。这使得升级,版本一致性以及许多其他事情比运行所有包括各种版本的东西的人们要好得多。
最小,完整和可验证的示例
典型包含。在Linux上,默认为/usr/include/
等。在Windows VS中,移至$(IncludePath)
变量中指定的位置。
#include <iostream>
int main() {
std::cout << "hello, world" << std::endl;
return 0;
}
现在假设我们将包含路径设置如下:
C_INCLUDE_PATH=192.0.2.17://usr/include;/usr/include;
以上内容将首先在192.0.2.17处检查远程服务器,以查看iostream
库是否存在。如果失败,将检查/usr/include
。
这有点说明问题:
#include <192.0.2.17://iostream>
int main() {
std::cout << "hello, world" << std::endl;
}
谢谢,基思:^)
答案 0 :(得分:2)
由于您仍然想要版本控制 ,因此您可以只使用git(就像成千上万个其他项目一样)。因此,每个用户都有所需的本地副本。
要回答原始问题:不。我不知道有任何支持这种包含方案的预处理器。
答案 1 :(得分:1)
我不知道有任何编译器可以远程检索包含文件或库,因此您不能直接执行此操作。
您能做的最好的事情就是将这些依赖项放在可以挂载的NFS共享上,然后将该路径添加到包含路径中。
答案 2 :(得分:1)
我不会在这样的代码中添加对此的引用,正如dbush所说,您必须增强预处理器。
但是在Make系统中可能有一些可爱的方法可以做到这一点。也就是说,例如,如果您使用的是Make,则可以在Makefile中添加强制刷新数据的步骤。
但是,我建议这是错误的,因为不仅仅是需要刷新的包含文件。如果包含项已更改,则相关代码也可能已更改,并且您也将需要更改。您不可思议的#include内容不会做任何事情来确保人们拥有include所针对的正确代码/库。
我不确定为什么不能正确使用源代码存储库来解决这个问题。