Re: [Boost-build] CVS: boost/tools/build/v2/build generators.jam, 1.100, 1.101 targets.jam, 1.197, 1.198

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-08-07 02:00:19

Vladimir Prus wrote:
> Rene Rivera <grafikrobot <at> gmail.com> writes:
>> Vladimir Prus wrote:
>>> On 8/2/06, Rene Rivera <grafik <at> users.sourceforge.net> wrote:

> Are you saying those other comments are not sufficient too?

Yep.

> That most likely 
> true, but that does not mean we should not try to improve commenting for new 
> checkings. Those other comments were probably written years ago, when I did not
> realize how really important comments are.

Sure, hopefully things will get better. But my changes show how someone 
relatively new can do things that might be superfluous or wrong.

>> I have no clue. But then again the run rule doesn't say what happens 
>> when it returns nothing.
> 
> I can fix that part; but that does not change the fact that 'can-build' is 
> under-commented.

I changed the gcc generator to use run and removed the can-build. And I 
added a small comment to generator.run that might help the next person 
who runs into this. You might want to tweak the comment with a better 
explanation.

>> OK, didn't notice there was a cache being use. May I suggest better 
>> names for such variable. Perhaps something that has the word cache in 
>> it, like "viable-generators-cache". I'll go fix the cache key problem 
>> though 
> 
> I'm not sure about longer name -- won't that increase memory consumption of 
> bjam?

Yes it would, but the values are likely to take up much more room. And I 
would think that understandable programs are more important. Perhaps 
just a comment indicating it's creating a cache would be enough.

>> If by "aborted" you mean that it should print a warning and skip 
>> building the dependent's target? Then yes. How can a target be made to skip?
> 
> You need to modify abstract-target.generate so that it can return 'skipped' 
> return value, and adjust all callers to act accordingly on 'skipped' value. 
> That's gonna be a lot of work, though.

Would having it return a special "skipped-target", that can never be 
selected, work?

>>> I still don't understand why *failure* to build a target should become a
>>> warning.
>> Because skipping unbuildable targets has been the expected behavior of 
>> Boost.Build from the start. 
> 
> Well, we don't know if that's the behaviour users really want -- it was not 
> documented like that, and nobody ever complained about either V1 behaviour or 
> V2 behaviour.

Well in BBv1 not much was documented :-) But I do have some vague 
memories of discussions about this.

>> When users ask for something to get built it 
>> should build as much as it can and only reports problems at the end. But 
>> that's not really an argument, but an excuse. The real reason is that we 
>> don't want to force artificial barriers on building what we think are 
>> incorrect configurations. That just frustrates new users who might get 
>> fed up with an uncooperative build system. And it frustrates experienced 
>> users because it will prevent them from doing things that they know will 
>> work.
> 
> That's an argument for disabling runtime-link=static check.

Yes it is, which would make it behave like BBv1.

> We can discuss 
> that decision, but your change does something different. It seem to make V2 
> ignore all problems with building targets. So if no generators at all can't be 
> found, you still get just warning.

That is fixed. I accidentally removed the EXIT in that case.

> And dependents are still built. I don't 
> think such hiding of problems is good. Imagine that V2 will do 30 min build of 
> a large project, and then report about a problem, that will indicate the build 
> properties are wrong, and you need yet another 30 min build.

Well it currently reports problems at the start. But yes building 
dependents is a problem.

> Hmm, I start to think what you did could be done simpler. You can modify gcc 
> linking generators, so that for runtime-link=static it returns nothing. Then, 
> you can modify typed-targets so that when generators return nothing, warning 
> is emitted instead of error (probably, just for Boost). Then, you won't need 
> new generators method, as well as some of the changes you made.
> 
> This approach would simplify the code; though I still don't agree with target 
> skipping approach.

Hm, I wonder if an easier solution is to have the gcc toolset add a 
"<build>no" to the properties. Is that possible? It would seem to solve 
all the problems of skipping targets and dependents.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo