From: Deane Yang (deane_yang_at_[hidden])
Date: 2007-11-08 10:05:58
Vladimir Prus wrote:
> Let me try again.
A real-world project might have 100 targets. It's
> very likely that some of the targets have some requirements, and
> requirements are currently documented as "property that will
> always be present in build properties". It's not documented as
> "property that should be present in build request to this target to
> even build".
I have to be honest. You and David are much, much more experienced at
both software development and, specifically, designing the behavior of
Boost Build v2 than me. So I would definitely defer to your judgments.
I would only venture to say this:
It appears that Boost Build was originally designed for very large
projects involving 100 targets, which would probably consist of a
smaller number of libraries but built with different settings (static
vs. shared, single vs. multi threading, etc.). For example, the Boost
libraries. Also, it is often run as part of an automated process. So you
have a strong preference for "keep building if at all possible, even if
it is not what the user asked for".
The problem is that some of us use Boost Build for much, much smaller
projects, where we have fairly specific settings we want, and we don't
want the library or application built at all if Boost Build is confused
by what we are requesting. Because it is probably us who are confused,
Is it possible maybe to allow for a way to have a "small project
setting", say in the user-config.jam file, that cause BB to not build a
target (or maybe even just abort the build) if the requested settings
are not possible *and* produce a helpful error message listing all of
the properties, how they were set (for example, if they were set in a
particular Jamfile or Jamroot, report which one) and explaining where
the contradiction is.
I'm probably asking for something that is unrealistic, and I am open to
suggestions for what would be a more reasonable request.
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