Hi Ken, I did a short test. I installed bjam on Ubuntu 10.04 using the repository (bjam version 3.1.16). According to the manpage, this bjam version does not support the --version and --help arguments at all. Here's the shorter usage output using the -h argument:
$ /usr/bin/bjam -h Invalid option: -h usage: /usr/bin/bjam [ options ] targets... -a Build all targets, even if they are current. -dx Set the debug level to x (0-9). -fx Read x instead of Jambase. -jx Run up to x shell commands concurrently. -lx Limit actions to x number of seconds after which they are stopped. -n Don't actually execute the updating actions. -ox Write the updating actions to file x. -px x=0, pipes action stdout and stderr merged into action output. -q Quit quickly as soon as a target fails. -sx=y Set variable x=y, overriding environment. -tx Rebuild x, even if it is up-to-date. -v Print the version of jam and exit. --x Option is ignored. Also, Here's the output with --help, which according to the manpage of this version is not a valid argument: $ /usr/bin/bjam --help Unable to load Boost.Build: could not find "boost-build.jam" --------------------------------------------------------------- Attempted search from /home/tahoar/domy-2.5/src/mosesdecoder up to the root and in these directories from BOOST_BUILD_PATH and BOOST_ROOT: /usr/share/boost-build. Please consult the documentation at 'http://www.boost.org'. I used the -v argument with the results: $ /usr/bin/bjam -v Boost.Jam Version 3.1.16. OS=LINUX. Copyright 1993-2002 Christopher Seiwald and Perforce Software, Inc. Copyright 2001 David Turner. Copyright 2001-2004 David Abrahams. Copyright 2002-2005 Rene Rivera. Copyright 2003-2005 Vladimir Prus. The bjam Bash script's --version argument fails, but if it worked, the subsequent "grep" command would fail to find the output string you set in the Bash script. I went back to the version in 12.04 (bjam version 3.1.19). According to the manpage, it should support the --help argument, but in reality, it produces no help output and launches a full bjam session. The manpage does not list the --version argument, but in reality argument outputs yesterday's report. The -v argument gives a longer report as above, but with version 3.1.19. There are significant (& poorly documented) inconsistencies between the various bjam binary's command interfaces and their outputs (Debian distro versions 3.1.16 & 03.1.19, and your version). They make it difficult to use them with any confidence across different platforms. For example, reversing the lines in the Bash script only skips the system bjam on any Debian distro version for the last 2+ years (I searched on Debian.org) and forces the use of the moses copy of bjam. Would it be more reliable to remove references to the system bjam altogether from the Bash script? On Wed, 25 Jul 2012 18:39:30 -0400, Kenneth Heafield <[email protected]> wrote: > Hi, > > I've reversed the order of the checks, so that version goes first. > This way, your system bjam will fail the version check (as, > apparently, > it should) before it gets to --help. > > Kenneth > > On 07/25/12 12:14, Tom Hoar wrote: >> I built a new machine with Ubuntu 12.04 Server. I learned the >> default >> setup installs bjam. (all my previous installs were on systems >> without >> bjam installs). >> >> ~$ bjam --version >> Boost.Build V2 (Milestone 12) >> Boost.Jam 03.1.19 >> >> I'm using the last 20 July commit of Moses. My bjam command line is: >> >> src/mosesdecoder$ sudo ./bjam -j4 -a --debug-configuration >> --with-xmlrpc-c --prefix="/usr/local/lib/mosesdecoder" >> --install-scripts="/usr/local/lib/mosesdecoder/scripts" >> --with-irstlm=/usr/local --with-randlm=/usr/local >> --with-srilm=/usr/local >> >> The system hung with no stderr or stdout output. Top showed a single >> instance of cc1plus (not four per -j4) and it hung for about 30 >> minutes >> before I hit Ctrl-C. I traced the problem to the moses bjam shell >> script. If I remove the two lines "${bjam}" --help & --version, the >> compile completes fine. >> >> if >> bjam="$(which bjam 2>/dev/null)" && #exists >> [ ${#bjam} != 0 ] && #paranoia about which printing nothing then >> returning true >> ! grep UFIHGUFIHBDJKNCFZXAEVA "${bjam}" </dev/null >/dev/null #bjam >> in >> path isn't this script >> then >> #Delegate to system bjam >> exec "${bjam}" "$@" >> fi >> >> In my case, "${bjam}" resolves to /usr/bin/bjam. More >> troubleshooting found: >> >> 1) the "/usr/bin/bjam --help" command ignores the --help argument >> and >> tries to process the Jamfiles in the default folder. When issuing >> the >> "/usr/bin/bjam --help" command from a default folder without any >> Jamfiles, the command terminates and reports "error: error: no >> Jamfile >> in current directory found, and no target references specified." >> From >> the Moses folder and with the Bash script redirecting both stderr >> and >> stdout to /dev/null, started processing without the command line >> scripts >> and system hung. >> >> 2) The --version output is a different format than the "grep" search >> expects and the bjam Bash script skips the system bjam installation >> and >> moves on to the bjam distributed with Moses. >> >> For my purposes, I will remove the two lines. For the main trunk, >> the >> --help command should be removed at a minimum. The grep line would >> have >> to be re-designed to handle the new report format if you really need >> to >> identify the Boost version. >> >> Tom >> >> >> >> _______________________________________________ >> Moses-support mailing list >> [email protected] >> http://mailman.mit.edu/mailman/listinfo/moses-support > _______________________________________________ > Moses-support mailing list > [email protected] > http://mailman.mit.edu/mailman/listinfo/moses-support _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
