Re: [Boost-build] PING: bootstrap.sh is triply broken on MinGW

Subject: Re: [Boost-build] PING: bootstrap.sh is triply broken on MinGW
From: Stephan T. Lavavej (stl_at_[hidden])
Date: 2013-10-05 17:49:47

Ping - can this be fixed for 1.55.0?

Thanks,
STL

-----Original Message-----
From: Stephan T. Lavavej [mailto:stl_at_[hidden]] 
Sent: Saturday, August 24, 2013 2:34 PM
To: 'Boost.Build developer's and user's list'
Subject: [Boost-build] PING: bootstrap.sh is triply broken on MinGW

Double ping? I've got two patches here ready to be applied.

Thanks,
STL

-----Original Message-----
From: Stephan T. Lavavej [mailto:stl_at_[hidden]] 
Sent: Thursday, August 08, 2013 7:27 PM
To: 'Boost.Build developer's and user's list'
Subject: Re: [Boost-build] bootstrap.sh is triply broken on MinGW (two
patches offered)

Ping?

Thanks,
STL

-----Original Message-----
From: Stephan T. Lavavej [mailto:stl_at_[hidden]] 
Sent: Saturday, July 20, 2013 4:07 PM
To: boost-build_at_[hidden]
Subject: [Boost-build] bootstrap.sh is triply broken on MinGW (two patches
offered)

Hi,

(I sent this to the general Boost mailing list two days ago.
You can view the patches here without mailing list line-wrapping at:
http://nuwen.net/stuff/boost-bootstrap.patch .)

For over a year I've been suffering from bootstrap.sh being broken on
MinGW, although I figured out a horrible hackaround. In 1.54.0 two more
breaks appeared, and I figured out real fixes for them. I'd like to offer
my real fixes here, and request two things: (A) a real fix to replace my
horrible hackaround for the original bug, and (B) bootstrap.sh to be
tested on MinGW for each release, because it's clearly not receiving
sufficient coverage.

The first break appears to be tracked by
https://svn.boost.org/trac/boost/ticket/5680 and
https://svn.boost.org/trac/boost/ticket/6350 . The problem is that
bootstrap.sh and b2.exe don't agree on what MinGW should be called: is it
mingw or is it gcc? No permutations of toolsets passed on the command
lines work. I've used the following horrible hackaround in 1.49.0 through
1.54.0 inclusive:

diff -aurN boost_1_54_0/bootstrap.sh boost_1_54_0-fixed/bootstrap.sh
--- boost_1_54_0/bootstrap.sh	2013-03-09 14:55:05 -0800
+++ boost_1_54_0-fixed/bootstrap.sh	2013-07-18 00:12:38 -0700
@@ -215,7 +215,7 @@
 if test "x$BJAM" = x; then
   echo -n "Building Boost.Build engine with toolset $TOOLSET... "
   pwd=`pwd`
-  (cd "$my_dir/tools/build/v2/engine" && ./build.sh "$TOOLSET") >
bootstrap.log 2>&1
+  (cd "$my_dir/tools/build/v2/engine" && ./build.sh mingw) > bootstrap.log
2>&1
   if [ $? -ne 0 ]; then
       echo
       echo "Failed to build Boost.Build build engine"

Of course, this is completely unacceptable for other toolsets, but I
basically know nothing about Boost's build machinery, so I can't figure
out a real fix.

Ideally, bootstrap.sh followed by b2.exe would work automatically, without
toolsets being specified. However, I would still be extremely happy if it
worked with manually specified toolsets, as long as I didn't have to patch
or sed files.

The second and third breaks are new to 1.54.0 and are tracked by
https://svn.boost.org/trac/boost/ticket/8762 . Here are my fixes that
should work for all platforms:

diff -aurN boost_1_54_0/tools/build/v2/engine/build.jam
boost_1_54_0-fixed/tools/build/v2/engine/build.jam
--- boost_1_54_0/tools/build/v2/engine/build.jam	2013-05-20 21:14:18
-0700
+++ boost_1_54_0-fixed/tools/build/v2/engine/build.jam	2013-07-18 00:12:43
-0700
@@ -483,8 +483,8 @@
     make.c make1.c mem.c object.c option.c output.c parse.c pathsys.c
regexp.c
     rules.c scan.c search.c subst.c w32_getreg.c timestamp.c variable.c
     modules.c strings.c filesys.c builtins.c class.c cwd.c native.c md5.c
-    modules/set.c modules/path.c modules/regex.c modules/property-set.c
-    modules/sequence.c modules/order.c ;
+    [ .path modules set.c ] [ .path modules path.c ] [ .path modules
regex.c ]
+    [ .path modules property-set.c ] [ .path modules sequence.c ] [ .path
modules order.c ] ;
 if $(OS) = NT
 {
     jam.source += execnt.c filent.c pathnt.c ;

It appears that build.jam needs to use this .path machinery to generate
either forward slashes or backslashes. When forward slashes are literally
used, the bootstrap complains that it doesn't know how to make the
corresponding object files. Once this is fixed, the final break is
revealed:

diff -aurN boost_1_54_0/tools/build/v2/engine/build.sh
boost_1_54_0-fixed/tools/build/v2/engine/build.sh
--- boost_1_54_0/tools/build/v2/engine/build.sh	2013-05-20 21:14:18 -0700
+++ boost_1_54_0-fixed/tools/build/v2/engine/build.sh	2013-07-18 00:12:43
-0700
@@ -247,18 +247,18 @@
 BJAM_SOURCES="\
  command.c compile.c constants.c debug.c execcmd.c frames.c function.c
glob.c\
  hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c
make1.c\
- object.c option.c output.c parse.c pathsys.c pathunix.c regexp.c rules.c\
+ object.c option.c output.c parse.c pathsys.c regexp.c rules.c\
  scan.c search.c subst.c timestamp.c variable.c modules.c strings.c
filesys.c\
  builtins.c class.c cwd.c native.c md5.c w32_getreg.c modules/set.c\
  modules/path.c modules/regex.c modules/property-set.c modules/sequence.c\
  modules/order.c"
 case $BOOST_JAM_TOOLSET in
     mingw)
-    BJAM_SOURCES="${BJAM_SOURCES} execnt.c filent.c"
+    BJAM_SOURCES="${BJAM_SOURCES} execnt.c filent.c pathnt.c"
     ;;
 
     *)
-    BJAM_SOURCES="${BJAM_SOURCES} execunix.c fileunix.c"
+    BJAM_SOURCES="${BJAM_SOURCES} execunix.c fileunix.c pathunix.c"
     ;;
 esac

(It took me quite some time to figure out this one.) Although pathunix.c
compiles on MinGW, it doesn't work, causing the bootstrap to complain
about not being able to write its command file. The correct pattern to
follow (as correctly done in build.jam; you can see half of it at the
bottom of the build.jam diff here) is for pathnt.c to be used for mingw
and pathunix.c to be used for all other build.sh platforms (i.e. real
Unixes).

Thanks,
Stephan T. Lavavej