Re: [jamboost] Re: propagation of usage-requirements

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-16 11:22:55

On Thursday 16 December 2004 18:52, David Abrahams wrote:
> Vladimir Prus wrote:
> > Toon Knapen wrote:
> >>> OTOH, I can't see any case where propagating usage requirements all the
> >>> way up will hurt, so maybe it's time to revise the behaviour. Opinions?
> >>
> >> I definitly think it would be better to not only propagate
> >> usage-requirements to the direct dependents but also to the indirect
> >> dependents (i.e. dependents of dependents and so forth).
> >
> > Done -- change and a test are committed. (Patch attached for reference).
> > Let's see what comes of it.
>
> I have a lot of sympathy for the idea that mysterious unneeded #include
> and library search paths shouldn't show up in a target's build command
> just because of some long dependency chain. People will eventually (for
> debugging purposes at least) want to know what concrete command was used
> to build their software and it will be confusing and probably
> distressing if there's a bunch of unneccessary garbage in the
> command-line. That's one reason I feel strongly about eliminating the
> ../../../../back/to/my/directory chains. If nothing else they induce a
> lack of confidence in the build system.
>
> There ought to be a way to say "these are propagated only to direct
> dependents." In fact, I think that maybe ought to be the normal case.

I think it's a conflict between "explicit" and "convenient". No matter what 
guidelines are there ("explicit is better than implicit", for example), I 
often find that decision is not easy. In this case, Toon did not like too 
explicit behaviour. I think if extra paths will cause problems only for 
debugging, it's not a big deal.

- Volodya