Re: [jamboost] [bbv2] Issues; is it ready for primetime?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-04-21 01:11:13

On Thursday 21 April 2005 04:50, Rene Rivera wrote:
> 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.

I can add this easily, by copy-pasting v1 text.

> * 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).

That's a good question. We have those options:

1. Point to a specific doc location.
2. Check if any toolsets are configured. If not, invoke "using gcc; " on Unix 
and "using msvc ; " on windows.
3. Write a configure.py script that will check for all compilers.

> * Doing "bjam --v2" in a library subdir, for example libs/thread/build,
> causes the same set warnings, but also produces an error:
>
> C:/DevRoots/Boost/boost/tools/build/v2/build\targets.jam:1241: in
> construct from module object(typed-target)@16
> error: unable to construct ../../../libs/thread/build/boost_thread

That's the side effect of no toolsets being defined. But I guess I figured 
that out.

> If it's an error to not have toolsets configured, it should not warn
> about it but error, and exit.

Technically, you can use V2 without any C++ toolset -- if you're only using 
Boostbook, for example.

> * 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.

So, you mean that there should be implicit "using cw ; ", right?

> * 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".

Oh, I guess I forgot that "bjam --v2" should build something. Does "bjam --v2 
stage" work?

> * 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.

Noted.

> * 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.

This worked for me as recently as yesterday. How did you set HOME? Can you 
debug this further. When I set

set HOME=H:

in win2000 command shell, it works.

> 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
> there AFAICT)
>
> 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.

I'm sure the above issues can be solved for 1.33 timeframe. It's quite likely 
that we won't be able to solve *all* the issues, though. There's a lot of 
toolset specifics in V1, and in Boost Jamfiles so we can run in other issues.

But -- the time before release is exactly the right time for shaking those 
unobvious issues. If we could get regressions going (even unofficially), with 
V2 on gcc and msvc, it would be much easier to keep them working until 1.34. 
If we just delay all work till 1.34, we'll just get more issues. Say, I've 
spend quite some time synchronizing V1 and V2 test Jamfiles, and if we wait 
for 1.34, I'll have to do this again.

So, I think it's best to try getting V2 into shape for 1.33. If we run into 
unexpected issues, we can always backtrack.

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2