Re: [Boost-build] [BBv2] PCH problems (was: removing propertiesfroma property s

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 
>real-world
> > >case? Can you explain this to me? Should pch-related usage requirements
> > >*always* apply only to direct depenents? Are there any other corner 
>cases?
> >
> > This would be a real-world case. Especially for complicated projects 
>that
> > 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 
>adding
>them.
>
>Sorry for not being very helpful with coding this, but I promise to commit 
>the
>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 
>you
>add a comment explaining why they are special. I don't want to introduce
>generic mechanism for the sake of one use-case.

Sure.

- Reece