"David Abrahams" <dave@boost-consulting.com> schrieb im Newsbeitrag news:ullfqhzfx.fsf@boost-consulting.com...
"Bertolt Mildner" <Bertolt.Mildner@gmx.at> writes:
When started form a Windows Commandline (cmd.exe) bjam tries to create existing directories and of curse failes to do so!
For example when building boost::thread:
------------------------------------ ...found 205 targets... ...updating 20 targets... MkDir1
..\..\..\bin\boost\libs\thread\build\boost_thread.dll\cw\\threading-multi
Ein Unterverzeichnis oder eine Datei mit dem Namen "..\..\..\bin\boost\libs\thre ad\build\boost_thread.dll\cw\\threading-multi" existiert bereits.
mkdir "..\..\..\bin\boost\libs\thread\build\boost_thread.dll\cw\\threading- multi"
...failed MkDir1 ..\..\..\bin\boost\libs\thread\build\boost_thread.dll\cw\\threa ding-multi... ------------------------------------
(the german error-msg means "directory or file "..." allready exists")
As this causes targets to be skipped this is getting pretty annoying
...
As far as i understand the root of the problem is that the nativ
"mkdir" on
Win32 does not take any options to be quiet if the directory exists ("-p" on Unix).
No, that's not the problem. That rule normally does not run if the directory already exists. Did you perchance build your bjam from cygwin? A cygwin-built bjam only works under a Cygwin shell.
OK, so in my case the rule *does* run for existing dirs! Changing MKDIR ?= mkdir ; to MKDIR ?= \"mkdir.exe\" -p ; in allyourbase.jam "fixes" the problem (with cygwin in PATH). I built bjam with MSVC 6 ("build.bat msvc" in \tools\build\jam_src). Building bjam with CW 8.3 failed due to a crash in mwld.exe!?
It looks like allyourbase.jam tries to address this in the MkDir rule, but fails to.
The directory is a target. If the build system sees that it already exists, it won't try to create it. I can't imagine why this would fail for you unless you were using a mis-constructed bjam.
Ah.. I think i have found something! I have set "BUILD = debug release" and that causes very strange things to happen!
From program_options first bjam run with "BUILD = debug release":
----- gcc-C++-action ..\..\..\bin\boost\libs\program_options\build\libboost_program_op tions.lib\gcc\release"\cmdline.obj g++: no input files ++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -I"..\..\..\bin \boost\libs\program_options\build" -I"C:\BACKUP\Data\C++\boost" -I "C:\BACKUP\ Data\C++\boost" -o "..\..\..\bin\boost\libs\program_options\build\libboost_prog ram_options.lib\gcc\release"\cmdline.obj" "..\..\..\libs\program_options\build\ ../src/cmdline.cpp" --------------------------------------------------------------------------- ----- Second run with "BUILD = debug release": --------------------------------------------------------------------------- ----- MkDir1 ..\..\..\bin\boost\libs\program_options\build\libboost_program_options.li b\gcc\release" Ein Unterverzeichnis oder eine Datei mit dem Namen "..\..\..\bin\boost\libs\prog ram_options\build\libboost_program_options.lib\gcc\release " existiert bereits. mkdir "..\..\..\bin\boost\libs\program_options\build\libboost_program_optio ns.lib\gcc\release"" ...failed MkDir1 ..\..\..\bin\boost\libs\program_options\build\libboost_program_ options.lib\gcc\release"... --------------------------------------------------------------------------- ----- See attached file bjam.txt.zip for full output. When i unset BUILD or set it to either release, debug or <nothing> program_options build fine. For the thread lib i have to unset BUILD to make it build??? Setting BUILD with no value makes bjam crash until .jamdeps is removed!? HELP! Something is very very wrong here!
PS: I have tried to post this in gmane.comp.lib.boost.build but i always got mail that i should join <jamboost@yahoogroups.com>!
Why does that surprise you? That is the mailing list behind that NG.
Because it is nonsens to join a *mailinglist* when writing to a *newsgroup*? ;-) If i would want to join the mailinglist i would have done that in first place!? Bertolt ***************************************************************************** ** ** ** WARNING: This email contains an attachment of a very suspicious type. ** ** You are urged NOT to open this attachment unless you are absolutely ** ** sure it is legitmate. Opening this attachment may cause irreparable ** ** damage to your computer and your files. If you have any questions ** ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. ** ** ** ** This warning was added by the IU Computer Science Dept. mail scanner. ** *****************************************************************************