Re: [BBv2]some ideas

From: pal.tw (paul_lin_at_[hidden])
Date: 2003-10-31 01:50:27

Hi, Volodya:

Sorry for late reply...
--- In jamboost_at_[hidden], Vladimir Prus <ghost_at_c...> wrote:
> The same problem arisen with intel toolset, which, on linux, is 
> link-compatible with gcc, so yes, a solution is needed. If you 
could propose 
> one, that would be great. Basically, we need some way to say, 
> "<toolset>intel" is compatible with "<toolset>gcc", even if 
<toolset> is 
> link-incompatible. The devil is in the detail -- how to say that.
> 

This topic would focus on the relationships among value strings,
not only in two property-sets belong to two different targets
but also one property-set to single target.

I separate it into two parts.

A. property refinement in a target
B. the relationship between two target

A. property refinement in a target :

As everybody knows, when we build a target, applying
different property-sets to it may produce different variants.
BBv2 provides 'requirements', 'usage-requirements',
'default-build', and 'command line' mechanisms to
constitute the final property-set of a target.

No matter where the property-sets come from, the issue is
how they are refined and merged together. BBv2 decide
two property sets are link-compatible only if
there's no link-incompatible feature which has
different values in those property sets,
like '<threading>multi' and '<threading>single',
but not those of different features, like
'<target-os>freebsd' and '<toolset>msvc'.

As Volodya mentioned, it is possible that <toolset>intel
and <toolset>gcc are link-compatible on linux
(maybe <target-os>linux in the future).
Although he might mean the property-sets on two targets,
I think there might be the same situation for merging
property-sets on a target.

So I image that if it is possible to figure out
the relationships of properties, just like
conditional properties, but more powerful,
more kinds of relationships. Of course, the relations
are not limited to binary ones.
We can define some relation types in advance,
and then add the property-tuples to the relation-sets.

R1 = { (a, b), (a, c) ...}
R2 = { (a, b, c), (a, c, d)... }
.
.
.

BBv2 can refine property-sets according to
the relationships of properties. And conditional properties
is just one of the results from interpreting relations.

B. the relationship between two targets :

Like project relationships, they involve in passing attributes.
But in addition, build system must verifies
if the relationship is valid. BBv2 achieves this
by checking if the property-sets on them are link-compatible.
But some property-sets are link-compatible in some condition,
and link-incompatible in other condition,
like the situation Volodya mentioned.

So I image that there are constraints to determine whether
the property-sets on different targets are link-compatible or not.
They are also sets of tuples. And maybe we can find out
some common constraint pattern, such that if A exists,
then B and C are link-compatible.

Of cousrse, if property-tuples are too many, it is not efficient
to add them to relation-sets or constraint-pools one by one.

Therefor maybe we can adopt another way to declare a relation. 
To specify the property of the relationship of
two or more features. And some of the feature attributes
might be used to figure out the relationships of properties
in the same feature. For example,

--------------------------------------------------------------
feature target-os : WinNT Win2000 WinXP Win2003 : ... back-
compatible
--------------------------------------------------------------

Then target A with <target-os>Win2000 can be link-compatible
with library B with <target-os>WinNT, but target A
with <target-os>WinNT are not link-compatible with library B
with <target-os>Win2000.
----------------------------------------------------------------------

The build system interpret and validate the values of a feature
according to it's feature attributs when they appear
in a build request. I class the feature attributes into
three categories according to their characteristic.

1. specify the format of value strings, or more exactly,
the valid values of a feature, whether the feature has
default value or not, and whether it can be multi-valued or not.
-- "free" "optional" "path"

2. describe relationship between two targets or
one target and one external resource.
-- "dependency" "propagated" "link-incompatible"

3. helps to build system
-- "composite" "implicit" "incidental" "symmetric"

Maybe we can focus on one group at one time when we design.

Another thought, is it possible to realize inheritance of the 
properties?
I mean that the children can be treated as is-a parent.
Ex. <variant>profile is not a <variant>release.

So that I can say <target-os>Win95 and <target-os>WinNT are
<target-os>Win32 and <target-os>Win2000 is a <target-os>WinNT.
It is impossible to figure out a inheritance path
by using the subproperty mechanism.

- PAL