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

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-04-21 02:14:24

Vladimir Prus wrote:
> On Thursday 21 April 2005 04:50, Rene Rivera wrote:

I should have also pointed out that these are likely not the only 
issues. Just the ones I ran into. As I use BBv2 more I'm sure the list 
will grow.

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

Sure. But how will we get it to only show that text when they do "bjam 
--v2 --help" at the boost-root. Ideally it would be good to have the 
help string read from the Jamfile in the current directory.

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

Yes.

> 2. Check if any toolsets are configured. If not, invoke "using gcc; " on Unix 
> and "using msvc ; " on windows.

No.

> 3. Write a configure.py script that will check for all compilers.

No. Last thing we want is another layer.

What I've been adding is a set of auto-configuration modules for the 
tools I've had to set up. Those are the new tools/*-config.jam files. 
Each one attempts to automatically find and configure (using .. : ..) 
the tools. But wont do anything if it can't find the tool (well at least 
most of the time). It means that my user-config.jam has this:

import msvc-config ;
import cw-config ;
import python-config ;
import xsltproc-config ;
import boostbook-config ;
import doxygen-config ;

This is something we can make the default user-config have. So that 
first users have the best likelihood of things working without any work 
on their part.

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

Yep. It's not like I didn't know.. Just pointing out what new users are 
likely to complain about. Because it's the same kind of things they've 
complained about with BBv1.

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

Technically.. But as it's implemented boostbook doesn't work without a 
toolset.

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

Yes. But from the users perspective it's not implicit. They tend not to 
make the distinction between configuring and just using. We really want 
to strive for having Boost work right out of the box.

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

Don't know.. Haven't gotten that far ;-) As you probably saw from 
another post I've been trying to get the boostbook building to work.

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

I set up three different user-config files, in my real HOME dir, in 
C:\Boost, and the one in boost-root\tools\build\v2. Each has an ECHO 
telling which file it is..

C:\DevRoots\Boost\boost>set HOME=C:\Documents and Settings\grafik.KLUDGE

C:\DevRoots\Boost\boost>bjam --v2
@@@ BBv2/user-config.jam
...found 1 target...

C:\DevRoots\Boost\boost>set HOME=C:\Boost

C:\DevRoots\Boost\boost>bjam --v2
@@@ C:/Boost/user-config.jam
...found 1 target...

So it looks like it's not handling it when the path has spaces.

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

It's more than likely.. I can just about guarantee it. The question is 
can we solve *all* issues that put BBv2 below the experience that users 
currently get from BBv1. NOTE: I'm not talking about using BB for other 
projects. Just about the experience of downloading and installing the 
Boost distribution.

> There's a lot of 
> toolset specifics in V1, and in Boost Jamfiles so we can run in other issues.

It's my knowledge of all the BBv1 details that's making me think we 
aren't ready with BBv2.

> But -- the time before release is exactly the right time for shaking those 
> unobvious issues. 

I disagree. I think the Boost release should be about the "Boost C++ 
Libraries". Having a slight step backwards in the interface to 
building/installing the libraries will backfire with many user complaints.

Yes release time will shake up all kinds of issues but we really don't 
want users to pay for finding those 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.

I wasn't suggesting we delay all work until 1.34. I suggested that we 
work on making BBv2 as shiny as possibly right after 1.33. This would 
include _forcing_ the use of BBv2. So we would get rid of the v1 
directory, change the docs, not have the --v2 switch, move testing to 
BBv2, etc.

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

I don't think we have enough resources to get V2 into shape without 
sacrificing in other places. In order to have the option of backtracking 
we would have keep the current arrangement of maintaining and testing 
with BBv1 to ensure we can backtrack. Which means that, because I'm the 
one doing that BBv1 support, I would not be able to help with BBv2 (and 
I really want to!). So for me to devote resources to BBv2 I would have 
to stop BBv1 support. Which is just plain dangerous at this stage in the 
1.33 release schedule.

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