From: David Abrahams (dave_at_[hidden])
Date: 2007-11-07 17:24:09
on Fri Nov 02 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
> Deane Yang wrote:
>> Can we try to be more specific?
>> If you run bjam without explicit settings, then it should indeed try to
>> figure out what the most reasonable thing to do is. But I would love it
>> if bjam could report what it is choosing, so I can see if I am getting
>> something I don't want. It is not uncommon for me to accidentally
>> compile different libraries with slightly different settings and run
>> into real difficulties when I try to use them together in one project.
> This (high-level report of what is built) is something we can add.
>> If you run bjam with explicit settings, for example what Robert
>> originally tried:
>> --toolset=msvc-7.1 threading=single variant=debug,release
>> and bjam decides that it is impossible to deliver exactly what is
>> requested (in this case, single threading with shared runtime), then is
>> it not unreasonable for bjam to simply quit with a message saying "what
>> you requested is not possible", along with a suggestion on what might
> This might work in simple cases, but might not work in complex ones.
> Suppose you have a project with line 100 libraries. One of them should
> always be static. If you say on command line:
> do you still want an error message? Probably, when requesting a specific
> target, we can error or warn if the required properties cannot be obtained. Making
> build error out in general when some target needs to impose its requirements seems
> not very useful.
Okay, but be consistent about it.
Either you create straightforward rules for interpreting build
requests usefully with respect to target requirements, or you force
the user to be excruciatingly explicit in order to avoid hard errors
when you don't trust him to understand how build requests and target
requirements combine to produce real results. Pick one principle and
stick to it.
Rejecting the substance of
make any sense unless you're going to take Deane's suggestion.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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