Vladimir Prus wrote:
Mateusz Loskot wrote:
Steven Watanabe wrote:
Mateusz Loskot wrote:
For 1st example for the case 1), in trunk/libs/accumulators/example/Jamfile.v2, Boost headers are located by relative path and mysterious $(BOOST_ROOT)
exe example : main.cpp : <include>../../.. <include>$(BOOST_ROOT) ;
<include>$(BOOST_ROOT) can be replaced with <dependency>/boost//headers
Yet another option I've just learned, but...
What is the difference between using headers-only library by specifying this requirement using <source> and <dependency>?
The manual says:
"(...)a dependency on the target (...) (so it will be brought up-to-date whenever the target being declared is). The dependency is not used in any other way."
What does bringing up-to-date mean for headers-only? Also, the "not used in any other way" suggests to me that it does not implicitly update <include> directories.
Actually, for /boost//headers there's no difference between <source> and <dependency>. Every single metatarget in Boost.Build, when built, produces two things:
- actual targets (corresponding to files) - set of properties that must be propagated to dependents. These are known as usage requirements.
I understand.
Now, there are three predefined build properties:
1. <source> tries to consume the produced targets, and adds usage requirements. 2. <dependency> sets a dependency on the produced targets, and also adds usage requirements. 3. <use> only sets usage requirements
Now, because the 'headers' metatarget never produces any real file, only usage requirements, all three are exactly the same.
It makes perfect sense to me now. Great, I think I know how to configure Boost.Geometry examples and tests now. Thank you to you and Steven! -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org