[Boost-build] semantics of requirements (Was: single threaded build with msvc-7.1?)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-11-08 02:29:39

Deane Yang wrote:

> Vladimir Prus 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.
> 
> 
> Great! Can it be put in the queue somewhere?
> 
> 
>> 
>>> 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.
>> 
> 
> Try #2: Have two options:
> 
> Option #1: Do the run but give warning messages when something cannot be
> done
> 
> Option #2: Stop the run and give an error message when something cannot
> be done
> 
> One option should be the default and the other should be available
> through a command-line switch.
> 
> I would of course prefer Option #2 to be the default, and surely that
> would be the most common situation for bjam users?

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".

Now, assume the second interpretation is actually used. Say that exactly
1 of those 100 targets has <link>shared in properties -- because that
target is a plugin for a third-party tool (real example). You say on
command line:

        bjam link=static,shared

or

        bjam link=static

All 99 targets will be built as both static and shared, and the 1 remaining
will be built as shared. This seems as useful behaviour to me:

   - If an error is emitted instead, you'd have to explicitly build
   that one target.
   - If a warning is always emitted, it will annoy user and eventually
   user will stop caring

So, I think the best solution would be to add an option that would produce
output line this:

   - Build request link=static
      - Building a, link=static
      ....
      - Building z, link=shared*

Where targets built with properties differing from build request are marked by "*",
or in some other way. 

- Volodya