是否可以使 Microsoft build.exe 包含远程目录中的源?

发布于 2024-07-10 23:06:28 字数 244 浏览 6 评论 0原文

将源文件添加到多个目录之外(例如 ../../source.cpp 或 ../../../somewhere_else/source.cpp,与仅 source.cpp 或 ../source.cpp) WDK/DDK 构建中的 SOURCES= 声明会产生以下错误:

Ignoring invalid directory prefix in SOURCES= entry

是否可以在构建中包含远程源文件?

Adding source files more than one directory away (e.g. ../../source.cpp or ../../../somewhere_else/source.cpp, vs. just source.cpp or ../source.cpp) to the SOURCES= declaration in a WDK/DDK build yields the following error:

Ignoring invalid directory prefix in SOURCES= entry

Is it possible to include remote source files in a build?

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

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

发布评论

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

评论(3

通知家属抬走 2024-07-17 23:06:29

直接执行此操作是不可能的。 build 被明确设计为仅处理
源代码位于 sources 文件的同一目录或父目录中。 它不能使用任意位置的源文件。 特别是,它的依赖跟踪系统似乎无法解析和跟踪远程文件,因此它明确检查并强制所有文件都是本地的。

有两种常见的解决方案:

  1. 将远程代码构建为单独的库(通过同一构建项目中的另一个子项目/目录,或使用独立的构建步骤)。

  2. 为每个执行 #include "../../remote_source.cpp 的远程源文件放置一个本地存根,并将此本地存根添加到 SOURCES=这可以工作,但是 build/nmake不会跟踪 remote_source.cpp 中的依赖关系。如果 remote_source.cpp 更改,您必须touch本地代理源,或者以其他方式强制重建(删除本地代理 obj,运行 build 与 -cZ 或其他)。

It is not possible to do this directly. build is explicitly designed only to deal with
source code in the same or parent directory of the sources file. It cannot use source files from arbitrary locations. In particular, its dependency-tracking system seems unable to parse and track remote files, and therefore it explicitly checks and enforces that all files be local.

There are two common solutions:

  1. Build remote code as a separate lib (either via another subproject/directory in the same build project, or using an independent build step).

  2. Place a local stub for each remote source file which does #include "../../remote_source.cpp, and add this local stub to the SOURCES= list, instead. This will work, but build/nmake will not track dependencies in the remote_source.cpp. If remote_source.cpp changes, you will have to either touch the local proxy source, or otherwise force a rebuild (delete the local proxy obj, run build with -cZ, or otherwise).

梦境 2024-07-17 23:06:29

另一种方法是使用 source.inc 来包含这些文件。

An alternate way is to use source.inc to include these files.

坏尐絯℡ 2024-07-17 23:06:29

讨厌复活一个超级古老的话题,但我也刚刚遇到了这个。

另一种替代方法是在其中创建另一个源文件,该文件仅构建远程源的目标文件,因此基本上是一个名为 somewhere_else\sources 的文件,并为其提供相同的中间目录。

然后将“dirs”文件添加到原始目录并在其中指定远程文件夹。 然后通过向原始源文件中添加类似以下内容来直接链接到目标文件:

$(TARGETLIBS) = $(PROJECT_OBJ_ROOT)\$(O)\source.obj

这样,您不必将其编译为 lib,但构建会将其视为一个库,并且无需进行任何依赖项检查或关心位置即可进行链接。

如果您为它们提供相同的中间目录和相同的原始源文件名 (source.cpp),自然可能会遇到一些问题

Hate to resurrect a super old topic, but I just ran into this as well.

An alternate alternate way is to create another sources file inside that solely builds object files of the remote source, so basically a file named somewhere_else\sources, and give it the same intermediate directory.

Then add a 'dirs' file to your original directory and specify that remote folder inside. Then link directly to the object file by adding something like this to the original sources file:

$(TARGETLIBS) = $(PROJECT_OBJ_ROOT)\$(O)\source.obj

This way, you don't have to compile as a lib, but build treats it like one and links without any dependency checking or care of location.

Naturally you might run into some problems if you give them the same intermediate directory and the same original source file name (source.cpp)

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