|
Boost-Build : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-11-08 02:33:01
David Abrahams wrote:
>
> 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
>>> work?
>>
>> 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:
>>
>> link=shared,static
>>
>> 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.
I think the current rules are quite straightforward.
> Rejecting the substance of
> http://zigzag.cs.msu.su/boost.build/wiki/AlternativeSelection doesn't
> make any sense unless you're going to take Deane's suggestion.
What do you mean by "substance"? There are various ideas there,
and the one that appears most relevant here is treating properties
specified on command line differently from defaulted properties.
And I think don't think that's a good idea.
- Volodya
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