Boost C++ Libraries: Ticket #9051: jam build system refuses to work on windows, won't build on mingw-w64

component changed

viboes — Mon, 02 Sep 2013 19:32:57 GMT

component None → Building Boost

Steven Watanabe — Tue, 01 Apr 2014 20:43:25 GMT

The batch scripts should work for MinGW. You just have to run them from a cmd prompt rather than MSys.

There are also shell scripts (.sh) which should work under MSys in 1.55. I'm not sure what the status in 1.54 is.

I don't know what you mean by "the file extension is unrecognized." What files are you referring to? The source for b2 (formerly bjam) is part of the Boost distribution.

jmichae3@… — Thu, 03 Apr 2014 05:52:19 GMT

it's been a while, my guess was it is the .jam file extension that it not recognized. found bjam.exe however, due to multiple problems with the batch file used for the build with 1.55.0, it refuses again to build in either MSYS+mingw-w64 or mingw. just following the directions. there is a .bat file for this, but apparently there needs to be some better skills in writing one. providing a .bat and a .cmd file would be better - the .bat would work for DOS compilers, and the .cmd would work for windows. the .cmd shell has a LOT more features like

if condition (
) else (
)
if condition (
)

if /i @%somevar%@ neq @--help@   (
echo help text
) else (
)

rem this processes the whole dir tree of cpp files in 5 lines

for /f %%x in ('dir/s/b d:\projects\boost_1_55_0\*.cpp') do (
    rem %%~fx is the full file path
    %CC% %CCOPTS% -o %%~dpx%%~nx.o %%~fx
)

to do string extraction:

rem remove double quotes
set arg=%1
rem this works like AND
if @^"@==@%arg:~-1%@ if @^"@==@%arg:~0,1%@ set arg=%arg:1,-1%

and note that if anything has spaces in a filepath, surrounding it with double quotes will solve that problem. like "%%~fx"

to get help with the commands try adding /? to the command like

for /?
set /?

(that one is a wealth of info)

anonymous — Thu, 03 Apr 2014 05:55:37 GMT

if @^"@==@^%arg:~-1%@ if @^"@==@^%arg:~0,1%@ set arg=%arg:1,-1%

might be a correction to that. caret escapes a character sometimes. in the case of % in a file for for /f, %% is like %

Steven Watanabe — Thu, 03 Apr 2014 15:53:33 GMT

Huh? .bat and .com are both processed by cmd.exe. The differences in behavior are extremely minor. See also http://stackoverflow.com/questions/148968/windows-batch-files-bat-vs-cmd

anonymous — Fri, 04 Apr 2014 19:33:14 GMT

the differences between cmd and .bat are larger than just that small bullet list. BIG difference. the cmd shell is pretty much a shell scripting language. when a .bat is used, that functionality is lost - long filenames, long paths, etc. one issue that may come up is the long filepaths made by the boost directories. they are very deep and max out NTFS's filepath limit of 260 chars (fine for *nix which doesn't have a limit that I know of). also, .bat has a commandline limit of 127 chars. you should know these limitations before using .bat and program accordingly. there are workarounds for some of this, like shortened filenames. do a for /? to get help. for /f has a version of its variable expansion stuff which shortens filepaths to 8.3, but know that your compiled result will probably look the same and may not be compatible with whoever uses the headers.

Steven Watanabe — Fri, 04 Apr 2014 20:15:00 GMT

All the things that you've described as features of .cmd work in .bat scripts as well (and are used in the Boost scripts). Are you sure that you're running the scripts with cmd.exe? You're on Windows 7, so the ancient DOS command.com (which is much more limited) should not even exist.

jmichae3@… — Sat, 05 Apr 2014 05:48:35 GMT

32-bit machines have a command.com but x64 machines don't. the 32-bit machines' command.com DO act differently. cmd.exe basically calls command.com for DOS executables like .com .bat on those machines. on x64 .com and dos exe's do not execute in cmd shell (for one, because there is no DPMI). you are right about the fact that .bat and .cmd run the same on an x64 machine, testing on my x64 box has just confirmed this. but this was not the case with my 32-bit xp box when I had it. command.com has a much smaller subset of commands and features, a holdover from DOS - in fact, command.com came from DOS.