Open source mingw32 make:“；“输入行太长”；问题

我们有一个在Windows2003机器上运行的Makefile，我们正在使用mingw32 make。由于Makefile有许多include路径，因此它超过了cmd可以处理的8K缓冲区大小[Ref-因此编译会导致“input line too long”问题

我想知道以下情况-

优化Makefile的最佳方法是什么，因为我已经删除了不需要的编译器开关，包括路径等

有没有办法将所有包含路径放在一个.txt文件中，并将其导入Makefile。我找不到任何相同的mingw32文档

欢迎使用任何其他输入/提示/参考链接

谢谢，
-HJSblogger

我们采取的一种方法（这不是因为我们的命令行空间用完了，只是因为我们想要一个更干净的构建系统）是让每个“模块”执行其构建过程

例如，假设你有3个模块，A，B和C

控件makefile只调用具有相同目标的每个模块makefile

然后我们将目标设置为一致的clean、header、lib和exec

因此，控件生成文件类似于：

modules=A B C
clean:
    for i in $modules:
        ( cd $i ; make clean ; cd .. )
header:
    for i in $modules:
        ( cd $i ; make header ; cd .. )
lib:
    for i in $modules:
        ( cd $i ; make lib ; cd .. )
exec:
    for i in $modules:
        ( cd $i ; make exec ; cd .. )

具有其他模块所需头文件的每个模块在头文件阶段将这些头文件复制到中心位置。然后，在lib或exec阶段，每个模块只需使用该中心位置来定位其所有头文件。这也限制了模块仅使用发布到中心loca的头文件由其他模块执行

同样，创建exec阶段所需库的每个模块都将该库复制到一个中心位置。这大大减少了构建命令中的

-I

（include directory）和

-L

（library directory）子句

使用该方案，您只需在顶层执行

makeclean header lib exec

（或者在考虑依赖关系的情况下，为正确的makebuild而取消

clean

），就可以重建整个内容

这是解决问题的一种方法，但我真的想知道你是如何超过限制的。8K，即使每个路径有25个字符，也需要大约300个不同的包含路径。你的层次结构真的那么庞大吗

更新1：

如果您正在寻找一种不改变makefile“架构”的快速“脏”方法，那么您可以编写一个脚本，在给定目录列表的情况下，将所有头文件从这些目录复制到一个中心位置

然后将其作为所有规则的第一步运行，并修改编译行中的include语句，以仅引用该位置而不是大型列表。您甚至可以分阶段进行复制（例如，一次复制20个目录x 20次可处理总共400个目录）

这与我建议的解决方案具有相同的效果，只需对makefile进行较小的更改

更新2：

正如您在评论中所述，另一个解决方案是为路径添加别名

您应该能够使用

subst.exe执行此操作，例如：

> subst x: "c:\Documents and Settings\Pax\My Documents\Not my directory"
> dir x:
  Volume in drive X has no label.
  Volume Serial Number is 8AA3-703A

  Directory of X:\

  08/09/2009  10:12 AM    <DIR>          .
  08/09/2009  10:12 AM    <DIR>          ..
  24/08/2009  01:54 PM             6,409 p0rn_sites.txt
  09/07/2008  02:49 PM    <DIR>          downloaded_p0rn
  : : :
  09/07/2008  02:52 PM    <DIR>          other_suspect_stuff
                 3 File(s)         18,520 bytes
                18 Dir(s)  63,840,849,920 bytes free

> subst x: /d
> dir x:
  The system cannot find the path specified.

>subst x:“c:\Documents and Settings\Pax\My Documents\Not My directory”
>目录x：
驱动器X中的卷没有标签。
卷序列号为8AA3-703A
X目录：\
08/09/2009上午10:12。
08/09/2009上午10:12。。
24/08/2009 01:54 PM 6409 p0rn_sites.txt
09/07/2008 02:49下午下载
: : :
09/07/2008 02:52下午其他可疑物品
3个文件18520字节
18 Dir（s）63840849920可用字节
>subst x:/d
>目录x：
系统找不到指定的路径。
使用NACL SDK版本的“make”，我遇到了“命令行太长”的问题

问题的原因是Windows shell（cmd.exe）在命令行中有8191个字符大小限制：

问题是，当编译达到使用“ar”创建库的程度时，源文件太多，命令行太长

因此，为了解决这个问题，我必须更改“nacl_llvm.mk”文件：

其思想是创建一个“bat”文件，其中包含创建库文件必须执行的所有命令，然后逐个添加对象文件。
之后，“bat”文件将在正确的时刻执行

致以最诚挚的问候
Pax，谢谢你的回答。是的，这个构建非常庞大，有很多包含路径：）老实说，现在的重点是让系统在没有任何阻塞的情况下运行。谢谢-HJSBlogger@Pax：谢谢你的片段，我一定会尝试抓住这一个，看看它是否有效。与此同时，我也在寻找nto如果我们可以为路径做一个别名，例如C:\Inc\u Folder\src\…到X:的别名，那么我的所有Inc路径都将从X:\开始，从而减少cmd缓冲区的使用。我将cmd输出重定向到一个文件，发现在8K中，接近3K是因为每个组件的起始路径都很大。您对s的看法是什么ame。我仍在谷歌搜索并检查是否可行。我也会尝试并行地研究您的解决方案。@hjsblogger，我认为您正在寻找的命令是subst-检查答案的更新以了解详细信息。@Pax:由于Alias或subst在我的情况下不起作用，所以还没有解决。因此，现在我正在生成文件（.o）一个文件一个文件地归档，而不是一个组件一个组件地捣鼓。到目前为止一切都很顺利。@hjs，我们的想法不是关闭问题，而是把它留在这里，以防以后有人遇到同样的问题。关闭它会导致信息消失。更好的办法是接受答案（如果这确实是你解决问题的原因）别管它。
#
# LIB Macro
#
# $1 = Target Name
# $2 = List of Sources
# $3 = POSIX Link Flags
# $4 = VC Link Flags (unused)
define LIB_RULE
$(STAMPDIR)/$(1).stamp: $(LIBDIR)/$(TOOLCHAIN)/$(CONFIG)/lib$(1).a
    @echo "TOUCHED $$@" > $(STAMPDIR)/$(1).stamp

all: $(LIBDIR)/$(TOOLCHAIN)/$(CONFIG)/lib$(1).a
$(LIBDIR)/$(TOOLCHAIN)/$(CONFIG)/lib$(1).a: $(foreach src,$(2),$(call SRC_TO_OBJ,$(src)))
    $(MKDIR) -p $$(dir $$@)
    $(RM) -f $$@
# Comment this line!    
#    $(call LOG,LIB,$$@,$(PNACL_LIB) -cr $$@ $$^ $(3))

# Add these other lines
    $(shell echo cmd /C $(subst /,\,$(PNACL_LIB) -cr $(LIBDIR)/$(TOOLCHAIN)/$(CONFIG)/lib$(1).a) > create_lib.bat)
    $(foreach src,$(2),$(shell echo cmd /C $(subst /,\,$(PNACL_LIB) -r $(LIBDIR)/$(TOOLCHAIN)/$(CONFIG)/lib$(1).a $(call SRC_TO_OBJ,$(src))) $(3) >> create_lib.bat))
    create_lib.bat

endef