From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-11-23 11:52:28
Vladimir Prus wrote:
>On Wednesday 23 November 2005 19:02, Reece Dunn wrote:
> > > > PCH(A) --> LIB(A) -\
> > > > PCH(B) --> LIB(B)
> > > >
> > > > where LIB(B) inherits both PCH(A) and PCH(B) properties. :(
> > >
> > >Yes, usage requirements are propagated infinitely. Is the above
> > >case? Can you explain this to me? Should pch-related usage requirements
> > >*always* apply only to direct depenents? Are there any other corner
> > This would be a real-world case. Especially for complicated projects
> > have many libraries all dependant on each other, all (or most) using PCH
> > support.
>Why can't single PCH header be created, then?
If you had:
* geko.dll that rendered HTML web content and used a PCH;
* firefox.exe that used geko.dll and had its own PCH.
Here, geko and firefox might use a different PCH because firefox might pull
in the HTML, XML and CSS parsing headers, while geko might pull in a
graphics library and wouldn't want firefox's PCH.
This is common in windows (read Visual Studio) programming where each VC
project will by default have its own PCH file.
> > >I think it's possible to make pch-related feature "propagated to direct
> > >dependents only".
> > That would solve this problem. Do you know how to do this?
>Sure :-) Go to build/targets.jam, class basic-target, method
>compute-usage-requirements. Find line:
> result = [ $(result).add
> [ $(subvariant).sources-usage-requirements ] ] ;
>Remove properties you don't like for sources usage requirements before
>Sorry for not being very helpful with coding this, but I promise to commit
>patch even if <pch*> features are hardcoded here ;-) I'll add new feature
>attribute if and when we'll have another case where propagation to direct
>dependents only is desired.
Cool! I will submit the update later on today once I have had chance to
implement and check it.
>To clarify -- yes, I think it's fine to hardcode features here, provided
>add a comment explaining why they are special. I don't want to introduce
>generic mechanism for the sake of one use-case.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk