jam build system refuses to work on windows, won't build on mingw-w64

[jmichae3@…]

• batch files don't run for mingw-w64, they are only for MSVC++.

• no Makefiles

• Jam build system refuses to run on windows, the file extension is unrecognized, and no exe is provided for it to run like was previously the case.

• windows 7 64-bit and mingw-w64+MSYS (gcc) is my platform.

• I would give you the URL for the compilers, but this bug tracking system rejects them as spam, and there are numerous there, you want personal rubenvb 4.8 stdthread experimental. the x86_64 on the far left is the target processor, and the win32 or win64 on the right is the host (what you are running)

[Steven Watanabe]

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@…]

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 (
)

like

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]

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]

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]

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]

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@…]

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.