Re: [Boost-build] Recursively dependent libs

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-09-19 01:57:06

On Tuesday 19 September 2006 08:15, Rene Rivera wrote:
> Vladimir Prus wrote:
> > Rene,
> > in
> >
> >    https://zigzag.cs.msu.su:7813/boost.build/ticket/81
> >
> > you said V2 does not support recursively dependent libs. I believe you've
> > added the --start-group/--end-group to gcc command line to address that.
> > Is the issue now closed?
>
> No. I added the issue so that possibly one of the other options would be
> implemented. Unless we think that what I did is a real solution.
>
> > Incidentally, we have quite a lot of code to property order libraries on
> > command line for Unix. I'm not sure what to do with that code. It was
> > written because some folks said --start-group causes performance
> > degradation.
>
> It is slower. But at worse it's only 2 times slower than a regular build
> as using the group options is equivalent to repeating the libraries. 

Repeating the libraries once might not work -- if there are long chains of 
dependencies you might need to repeat the libraries N times.

> I 
> think the ideal solution is to only group recursive libs when we detect
> them (the last option I list on the issue). But I don't know how
> complicated would be to implement. I was hoping you could tell me ;-)

I think it's not hard. The 'order.order' method detects recursive dependencies 
anyway, so we only need to make it to return some flag indicating that cycles 
were found. But it requires that you accurately describe all the dependencies 
between libraries, and I never tried to describe circular dependency between 
prebuilt libraries.

> > It would be interesting to know if --start-group causes performance
> > degradation even if there are no circular dependencies and libraries on
> > command line are property sorted.
>
> Hm, good question! It's my understanding, but only from the docs, that
> it tries to be optimal in that it only rescans the libraries if there
> are unresolved symbols. So I would think that on the optimal, i.e. no
> interdependency libs it would scan only once.

Then we've done!

> > If yes, and that performance degradation is serious, we might need to
> > have an option 'allow circular dependencies'
> >
> > If no, then --start-group is way to allow circular dependencies without
> > penalizing common case, so we can just close the issue.
> >
> > Any options?
> >
> > BTW, why do you have circular dependencies between libraries at all?
>
> Truthfully I don't remember why. My vague memory is that it's not my
> code that has it, but some third party code I use. I personally don't
> intentionally have them as I know how painful they are to make work :-)

Ah, ok.

- Volodya

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