Re: Spec draft

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-06-17 10:20:40

Vladimir Prus <ghost_at_[hidden]> writes:

> [moving to the mailing list]
>
> David Abrahams wrote:
>> Vladimir Prus <ghost_at_[hidden]> writes:
>> > David Abrahams wrote:
>> >> > Yes, but there's another case:
>> >> >
>> >> > lib foo : a_gcc.cpp : <toolset>gcc ;
>> >> > lib foo : a_msvc.cpp : <toolset>msvc ;
>> >> > lib foo : a.cpp ;
>> >> >
>> >> > To represent this using conditional properties, you'd need
>> >> >
>> >> > lib foo : <toolset>gcc:a_gcc.cpp <toolset>msvc:a_msvc.cpp
>> >> > <toolset>!gcc&&<toolset>!msvc:a.cpp ;
>> >>
>> >> Whast's wrong with:
>> >>
>> >> lib foo : <toolset>gcc:a_gcc.cpp <toolset>msvc:a_msvc.cpp
>> >> <toolset>:a.cpp ;
>> >
>> > The problem is that <toolset>:a.cpp is not defined ;-) The only two
>> > contexts where feature names alone are allowed are generator matching and
>> > flags. In both context it means "any value of feature". I'm sure you have
>> > some other semantic in this case, but you did not tell which.
>>
>> I mean "any value of feature"... except those values which are being
>> used as a more-explicit condition, and thus overridde this condition.
>
> "used as a more-explicit condition" --- you mean that if <toolset>gcc is used 
> in condition anywhere in this target?

Yes.

>> >> Examples, please?
>> >
>> > lib foo : : <name>gcc_r <toolset>gcc <variant>debug ;
>> > lib foo : : <name>gcc <toolset>gcc <variant>release
>> > lib foo : : <name>msvc <toolset>msvc ;
>> > lib foo : foo.cpp ;
>> >
>> > IMO, this will explode to:
>> >
>> > lib foo : :
>> > <toolset>!msvc&&<toolset>!gcc||(<toolset>gcc&&<variant>!release&&<variant
>> >>!debug):<source>foo.cpp <toolset>msvc:<name>msvc
>> > <toolset>gcc,<variant>debug:<name>gcc
>> > <toolset>gcc,<variant>release:<name>gcc_r
>>
>> Oh that's just too weird! Some of those requirements are used for
>> matching (toolset, variant), and some get imposed (name)? I think I
>> understand something Ali was complaining about now!
>
> Somehow, I do not remember user complains about it. Moreover, this is 
> *precisely* how requirements work. Non-free requirements can be used for 
> matching. If you have <toolset>gcc in requirement, the target won't built 
> with any other toolset. Free requirements are just added.

I'm sure it works fine for users - it's perfectly easy to intuit how
things behave in most cases; I just now begin to agree with Ali that
it bends the brains of implementors/extenders.

>> Anyway, I think it explodes to something like:
>>
>> lib foo : :
>> <toolset>gcc,<variant>debug:<name>gcc_r
>> <toolset>gcc,<variant>release:<name>gcc
>> <toolset>msvc,<variant>:<name>msvc
>> <toolset>,<variant>:<source>foo.cpp
>> ;
>
> First off, to support this syntax you'd need the same logic which now selects 
> alternative, right? Second, looking at this, I don't think it's obvious that 
> only one line will be selected. 

That's why there are proposals for grouping. It's not fully
fleshed-out, of course ;-)

Let me back up a bit:

The _goal_ of the exercise of getting rid of alternatives was to
rationalize the process of generating virtual targets from their
specifications. I believe:

a. In *principle* it's possible to rewrite alternatives as
conditional properties, possibly with syntax not yet
specified.

b. Given a), we have accomplished the _goal_ with the pseudocode
Ali posted.

c. If there is no *sensible* way to write/represent alternatives
as conditional properties, it should be possible to reverse
process a) and reintroduce alternatives without compromising
the _goal_.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com