From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-04-20 19:50:59
These are observations from as close to a naive user as I can emulate.
Which for BBv2 and me is not that hard :-) I'm starting from the most
likely situation end users are going to. Meaning just downloaded the
Boost distribution, unpacked it, and nothing else.
NOTE: This is an informational email. I'm actually working on fixing
some the issues I'm posting about.
* No user inline help for install. In bbv1 doing "bjam --help" at the
boost-root showed the customary user level help for building and installing.
* Doing "bjam --v2" at boost-root gives a variety of warnings. One of
those about no toolset being configured and to consult docs. It should
point out where the docs are (URL, and local).
* Doing "bjam --v2" in a library subdir, for example libs/thread/build,
causes the same set warnings, but also produces an error:
construct from module object(typed-target)@16
error: unable to construct ../../../libs/thread/build/boost_thread
object(typed-target)@16.generate from module object(typed-target)@16
generate-really from module object(main-target)@1
object(main-target)@1.generate from module object(main-target)@1
object(project-target)@14.generate from module object(project-target)@14
C:/DevRoots/Boost/boost/tools/build/v2\build-system.jam:180: in load
from module build-system
C:\DevRoots\Boost\boost\tools\build\v2/kernel\modules.jam:259: in import
from module modules
boost-build from module
C:\DevRoots\Boost\boost\boost-build.jam:12: in module scope from module
If it's an error to not have toolsets configured, it should not warn
about it but error, and exit.
* Doing "bjam --v2 toolset=cw" at boost-root gives the configuration
warnings as above. It also gives error message about "cw" not being a
know feature of toolset. Two things, it should at minimum error and exit.
Second, it _really_ should let you specify the toolset on the command
line and it should look for that toolset and only complain if it can't
init/find the toolset.
* After adding "using cw ;" to the user-config.jam, and doing "bjam --v2
toolset=cw", or "bjam --v2 cw". It only shows the warnings about python,
and ICU, and does nothing except "found 1 target".
* If one tries to use the Python support (using python : ...), and the
MSVC toolset is not configured it complains with.. because it doesn't
know about the toolset.
error: "msvc" is not a known value of feature <toolset>
error: legal values: "cw"
[..and a bjam stacktrace..]
At worse it should detect that and give a meaningful response and
EXIT. At best the toolset feature issue needs to be resolved.
* Created a user-config.jam on my %HOME% dir. But instead it's loading
the one in tools/build/v2/. This one is a *critical* problem for users
because even after getting over the immediate non-configuration
problems. Attempting to configure per instructions doesn't seem to work.
Those are some of the things I found while getting up to speed with
BBv2. To me it doesn't look like we are ready to make BBv2 the front end
for users to interact with. As it stands it would look like a step
backwards from the users point of view. (Although it's fairly close to
My suggestion going forward given the 1.33 timeframe is to keep BBv1 for
the 1.33 release. As soon as that's out we can officially abandon BBv1,
by archiving it, removing it from the tree, etc. And then concentrate on
putting BBv2 in shape ASAP to be ready for the 1.34 release.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk