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

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-04-23 15:14:07

Vladimir Prus wrote:
> On Thursday 21 April 2005 11:14, Rene Rivera wrote:
>>>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.

And if you are in macosx it uses darwin.. But ultimately that is a 
fragile way of doing it. And for BBv1 it was only a kludge, so hopefully 
we can do better ;-)

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

Well the "import" vs. "using" is only because it's experimental right 
now. Having the same effect with only "using" would be ideal.

As for a different file.. I personally think it's good to separate the 
code for detecting the tool, from the code for using the tool. What I 
noticed is that the toolset files are large, mostly because they are 
mostly a bunch of logic for tool detection/setup and this just makes the 
toolset code hard to read. I'd like to move all the detection logic to 
separate files so that: a) they don't intrude on the toolset options 
code, b) they can be maintained independently.

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

Sure doing the "using" interface is ideal, but I said above having the 
detection and operation code in one file is less than ideal. How about 
changing "using" so that it loads and calls the code in *-config.jam. 
That the "using" interface is the same, but we get the code separation 
benefits.

>>So it looks like it's not handling it when the path has spaces.
> 
> Ok, I'll test this.

Seems to work nicely after you fixed it, by the way :-)

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

OK. And I'll bring up, and possible fix, any additional issues I find as 
I use BBv2 more. Which I ran into the issue of the BBv2 variant/version 
tag not matching the BBv1 behavior, and fixed it.

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

Sure. Didn't we already have someone who volunteered to run BBv2 testing 
runs?

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

Well hopefully not as long as 1.32 :-)

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