Boost logo

Boost-Build :

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

Vladimir Prus wrote:
> Rene Rivera <grafikrobot <at>> writes:
>> Vladimir Prus wrote:
>>> On 8/2/06, Rene Rivera <grafik <at>> wrote:

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


> 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 that might help the next person
who runs into this. You might want to tweak the comment with a better

>> 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. -
-- rrivera/ - grafik/
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at