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

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

On Thursday 21 April 2005 11:14, Rene Rivera wrote:

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

Well, we can use code like:

import project ;
if [ project.attribute $(__name__) location ] = "."
{
ECHO "Help message" ;
}

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

Why? Isn't this what V1 essentially does. If I run "bjam" it uses gcc, without 
a need for explicit configuration.

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

I'm not sure this is the best approach. In particular, now both msvc-config 
and msvc have some logic to detect msvc location. Also, this introduces 
another file related to msvc, with different name, and with different way of 
using ("import" as opposed to "using"). This might be confusing.

Maybe, a better approach is to modify "msvc" so that

using msvc ;

does not produce any warnings and does nothing if msvc is not found?

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

It works as soon as you're not using quickbook, I believe.

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

Why, they did not wrote it themself, so it's implicit for them.

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

I certainly agree.

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

Ok, I'll fix this, meanwhile.

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

Ok, I'll test this.

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

I see your arguments. Let's try this then: I'll go on fixing issues with V2 
regressions results on Linux. When I'm done, I'll ask for help on other 
system. At the same time, it would be great to start running regression
tests with V2. We don't need all compilers, or the same frequency, but we need 
to run them to make sure no new issues appear.

And when we decide to fully switch to V2, we'll just have to add more 
compilers to V2 regression tests and resolve new issues.

The time for the full switch can be preliminary set to after 1.33. But, then, 
let's see how long 1.33 will take ;-)

- Volodya

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