Apache OpenOffice (AOO) Bugzilla – Issue 16131
W32-4nt: $(MKDIR) ... Command line too long
Last modified: 2003-07-31 09:17:08 UTC
This is a follow-up to issue 15974 (old 4NT fails to build pyuno/zipcore) In pyuno/zipcore you can get the 'Command line too long' error from 4nt for the "call %PERL% %SOLARENV%\bin\mkdir.pl %1&" command, see Joergs logfile below. The problem is that the maximum command line length for 4nt is version depended. The version 4.01 has a 2047 byte limit, that's why I normally don't get this problem, but version 3.02b (The version Sander uses) has a 511 byte limit, see http://www.jpsoft.com/h4nt.htm the 3.02B version. I'm assigning this issue to you, ause, because you're the build environment specialist. I see a few solutions: * Bump the requirement to 4NT 4.x * Change the way $(MKDIR) is used. E.g. use the cygwin /bin/mkdir instead of $(MKDIR) -> mkdir.btm -> mkdir.pl (Brrrrr), just set MKDIR=mkdir and avoid a shellmeta. (But this propably requires cygwin 1.3.x, I don't know how good (if any) the mkdir of b20 was) * Don't use 4NT ;-) --- [z:\oo1.1beta2\pyuno\zipcore]dmake z:\oo1.1beta2\solenv\bin\mkdir.btm ..\wntmsci7.pro\bin\python-core-2.2.2 ..\wntmsci7.pro\bin\python-core-2.2.2\bin ..\wntmsci7.pro\bin\python-core-2.2.2\lib ..\wntmsci7.pro\bin\python-core-2.2.2\lib\lib-old ..\wntmsci7.pro\bin\python-core-2.2.2\lib\lib-tk ..\wntmsci7.pro\bin\python-core-2.2.2\lib\site-packages ..\wntmsci7.pro\bin\python-core-2.2.2\lib\test ..\wntmsci7.pro\bin\python-core-2.2.2\lib\test\output ..\wntmsci7.pro\bin\python-core-2.2.2\lib\test\data ..\wntmsci7.pro\bin\python-core-2.2.2\lib\encodings ..\wntmsci7.pro\bin\python-core-2.2.2\lib\email ..\wntmsci7.pro\bin\python-core-2.2.2\lib\compiler ..\wntmsci7.pro\bin\python-core-2.2.2\lib\hotshot ..\wntmsci7.pro\bin\python-core-2.2.2\lib\distutils ..\wntmsci7.pro\bin\python-core-2.2.2\lib\distutils\command ..\wntmsci7.pro\bin\python-core-2.2.2\lib\xml ..\wntmsci7.pro\bin\python-core-2.2.2lib\xml\dom ..\wntmsci7.pro\bin\python-core-2.2.2\lib\xml\parsers ..\wntmsci7.pro\bin\python-core-2.2.2\lib\xml\sax ..\wntmsci7.pro\bin\python-core-2.2.2lib\curses ..\wntmsci7.pro\bin\python-core-2.2.2\lib\plat-linux2 ..\wntmsci7.pro\bin\python-core-2.2.2\lib\config ..\wntmsci7.pro\bin\python-core-2.2.2\lib\lib-dynload rem @echo off iff "%PERL%" == "" then call %PERL% %SOLARENV%\bin\mkdir.pl %1& 4NT: Z:\OO1.1BETA2\SOLENV\BIN\MKDIR.BTM [5] Command line too long rm -f ..\wntmsci7.pro\bin\python-core-2.2.2\bin\python.exe cat z:\oo1.1beta2\solver\644\wntmsci7.pro\bin\python.exe > ..\wntmsci7.pro\bin\python-core-2.2.2\bin\python.exe ---
Set target
Created attachment 7184 [details] fixed line too long; cleanup
two more to fix: - $(MKDIR) requires prefixing with "+-" - all occurances of "$?" are ment to be "$<" btw.: this makefile is not a beauty anyway, but does it do anything usefull on windows? maybe "zipcore" deserves an "u" in "prj/build.lst".
>two more to fix: >- $(MKDIR) requires prefixing with "+-" why? unitools defines MKDIR=+$(SOLARENV)$/bin$/mkdir.btm for 4NT and an error might be correctly caught. Volker
it's rather the "-" that's required as "$(MKDIR)" returns an error on unix if the directories already exist.
> btw.: this makefile is not a beauty anyway, Have a look at the most recent version on ooo11rc branch, I am always open for improvement suggestions. BTW, maybe you have an idea howto fix #i15917#. >but does it do anything > usefull on windows? Yezz, the same as on unix (otherwise we wouldn't have problems on win) > maybe "zipcore" deserves an "u" in > "prj/build.lst". no
hi! nice to get in contact again :-) i just recognized that the construc for "FIND*" doesn't work at all here in my 4nt shell (ver 2.5). it doesn't change the directory :-( but i found something like this to work: FINDDIRS:=$(subst,/,$/ $(shell +$(FIND) $(SOLARLIBDIR)$/python -type d ))A XFINDDIRS=$(subst,$(SOLARLIBDIR)$/python, $(FINDDIRS)) btw.: use ":=" to avoid reevaluation that renders my modification to "dirs" useless as it now get gets a command line that's too long anyway... but see below for other ideas. that's also why my zip on windows was quite empty :-( suggestions for improvement: - FILES should depend on dirs to make sure the directories exit (make FILES phony too :-() - better: put something like "-$(MKDIR) $(@:d)" in the rule for copying to avoid "dirs" completely - even better: copying all those "*.py" files takes quite a while. storing a zip file on SOLVER may help. that would also fix the problem of creating all those dirs. - "$<" will give better results than "$?" as it doesn't contain indirect dependencies. - why not use a regular "ZIPnTARGET"? they now support changing there first. i'll have a look at #i15917# later because i'll first send this comment :-)
Thx for your comments, I have fixed this now on ooo1rc. Especially $(@:d) was quite useful. So I close this issue.
fixed
closing fixed issues for 1.1. release.