2009-09-08 163 views
4

我们有一个在Windows 2003机器上运行的Makefile,我们使用的是mingw32-make。由于Makefile有许多包含路径,它超过了cmd可以处理的8K的缓冲区大小[参考 - http://support.microsoft.com/kb/830473/EN-US/,因为编译导致“输入行太长”问题。mingw32-make:“Input line too long”issue

我想知道以下 -

  1. 什么是优化的Makefile的最好方式,因为我已经删除不需要的编译器开关,包括路径等

  2. 有什么办法我们可以将所有INCLUDE路径放在一个.txt文件中,并将其导入到Makefile中。我找不到任何相同的mingw32文档。

任何其他输入/提示/参考链接是最欢迎

感谢,
-HJSblogger

回答

3

一种方法我们采取了(这是不是因为我们跑出来的命令行空间,只是因为我们希望有一个更清洁的构建系统)是让每个“模块”吗其构建通行证。

因此,举例来说,假设你有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阶段,每个模块只需使用该中心位置来定位它的所有标题。这也限制了模块仅使用那些由其他模块发布到中心位置的头文件。

同样,每个创建exec阶段所需的库的模块都将该库复制到中央位置。这极大地减少了构建命令中的-I(包含目录)和-L(库目录)子句。

使用该方案,您可以通过在顶层执行make clean header lib exec来重建整个事件(或者考虑到依赖关系,不要在clean之前进行适当的构建版本)。

这是解决您的问题的一种方法,但我实际上想知道如何超出限制。 8K,即使每个路径有25个字符,也需要大约300个不同的包含路径。你的等级体系真的很庞大吗?

更新1:

如果你正在寻找一个quick'n'dirty方式得到它的工作不改变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. 
+1

Pax,谢谢你的回答。是的,构建是相当庞大的,并有很多包括路径:) 说实话,现在的重点只是使系统运行没有任何堵塞。 谢谢, -HJSBlogger – hjsblogger 2009-09-08 06:31:36

+0

@hjsblogger,如果你正在寻找一种快速的方法来让它工作,编写一个脚本,给定目录列表,将所有的头文件从这些目录复制到中央位置。然后将其作为所有规则的第一步,并将编译行中的include语句修改为仅引用该位置而不是大型列表。您甚至可以分阶段进行复制(例如,一次20个目录x 20次,总共可处理400个目录)。 – paxdiablo 2009-09-08 06:39:57

+1

@Pax:谢谢你的代码片段,肯定会试图抓住这一个,看看它是否有效。与此同时,我还在研究是否可以为ALIAS路径例如C:\ Inc_Folder \ src \ ..这样的路径创建一个ALIAS到X:这样我所有的INC路径将从X:\开始,从而导致使用量减少的cmd缓冲区。 我将cmd输出重定向到一个文件,发现在8K之外,由于每个组件开始的起始路径很大,接近3K。 你对此有何看法。我仍在使用Google搜索并检查是否有可能。我也会尝试并行查看您的解决方案。 – hjsblogger 2009-09-08 07:21:38

0

使用的“让”我有“命令行太长”的问题NACL SDK版本。

的问题的原因是,Windows壳(cmd.exe的)在命令行8191字符大小限制: http://support.microsoft.com/kb/830473/en

的问题是,当编译达到通过使用创建库的点“ar”,源文件太多,命令行太长。

因此,要解决这个问题,我不得不改变“nacl_llvm.mk”文件:

# 
# 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 [email protected]" > $(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 [email protected]) 
    $(RM) -f [email protected] 
# Comment this line!  
# $(call LOG,LIB,[email protected],$(PNACL_LIB) -cr [email protected] $$^ $(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 

的想法是创建一个“bat”的文件,必须执行创建的所有命令库文件,然后逐个添加目标文件。 然后在适当的时候执行“bat”文件。

致以问候