From: J. van der Wulp (jwulp_at_[hidden])
Date: 2006-11-26 14:51:01
> In this case, the <install> target will get <build>no -- since usage
> requirements are propagated all the way up. Do you suggest that 'install' is
> specially coded to still install the other targets?
Yes. To me it seems seems a natural choice. We maintain a toolset with
lots of tools. It can be that some tools cannot be built because library
X or Y is not installed. But the user accepts this and wants to install
the rest of the tools that can be build. I don't know how difficult this
would be to realise at this moment, but to me using the build property
looked like the perfect solution.
> What precisely are you trying to achieve with <build>no in properties? Do you
> want to avoid compiling lots of source files that depend on missing libraries
> and won't likely compile anyway?
Yes this is exactly the intention. I want to use the build property as a
filter method. The problem we face at the moment is that some
libraries and binaries are being build that should not build because for
instance libXML is not available. To do this the site-config contains an
alias target with the same name as the normal library target, with
<build>no in requirements and usage-requirements. Is there a better way
to solve this same problem?
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