Quantcast

feature, properties, variants, and all the rest

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

feature, properties, variants, and all the rest

Stefan Seefeld-2
Hello,

I'm still working on my b2 Python prototype (haven't given up just yet !
;-) ). Instead of reinventing everything from scratch, I'm trying hard
to reuse ideas from b2 wherever I can. However, that is quite hard,
given the sparseness of its documentation...

Right now I'm trying to understand properties and how they propagate
from the command-line & jamfiles to targets and actions.

So let me outline my understanding of these concepts, combined with a
few basic questions I have:

* Property sets are sets of properties (duh !). What does the
'PropertySet' class (in build/property_set.py) add over a simple set()
(or list()) of property instances ?

* A Property is a feature with an associated value. What is a LazyProperty ?

* A Feature is a type of a property: it defines certain property
attributes, as well as ways to interpret it. Feature values are
typically restricted to finite sets of values, unless they are 'free'.
What attribute decides whether values are accumulative or exclusive ?
(For example, the 'link' value is either 'static' or 'shared', but
'include' is an accumulative set of paths.) Further:

  - what is a 'sub-feature' ?

  - what is a 'symmetric' feature ?

  - what is a 'composite' feature ?

It would be great to see examples of the above. I promise to try to
capture my understanding in a document, so this will at least result in
improved documentation. Please help ! :-)

Many thanks,

        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Steven Watanabe-4
AMDG

On 12/23/2016 09:05 AM, Stefan Seefeld wrote:

> Hello,
>
> I'm still working on my b2 Python prototype (haven't given up just yet !
> ;-) ). Instead of reinventing everything from scratch, I'm trying hard
> to reuse ideas from b2 wherever I can. However, that is quite hard,
> given the sparseness of its documentation...
>
> Right now I'm trying to understand properties and how they propagate
> from the command-line & jamfiles to targets and actions.
>
> So let me outline my understanding of these concepts, combined with a
> few basic questions I have:
>
> * Property sets are sets of properties (duh !). What does the
> 'PropertySet' class (in build/property_set.py) add over a simple set()
> (or list()) of property instances ?
>

  It's more like a dict than a set.  The main
benefit is that it mirrors Jam, which makes
porting jam modules much simpler.  There are
also some functions specific to properties,
like target_path or base, free, propagated, etc.

> * A Property is a feature with an associated value. What is a LazyProperty ?
>

I have no idea, since there's no such thing in Jam.

> * A Feature is a type of a property: it defines certain property
> attributes, as well as ways to interpret it. Feature values are
> typically restricted to finite sets of values, unless they are 'free'.
> What attribute decides whether values are accumulative or exclusive ?
> (For example, the 'link' value is either 'static' or 'shared', but
> 'include' is an accumulative set of paths.) Further:
>

  Only free features can have multiple values.  In
retrospect combining 'multiple values' with
'values not from a predefined list' was probably
a mistake.  There are a number of cases where
the correct behavior is 'exactly one path',
for instance.

>   - what is a 'sub-feature' ?
>

  It's a feature that is only present when another
property is present:
Ex: <toolset>msvc-14.0 is actually shorthand for
<toolset>msvc <toolset-msvc:version>14.0
where <toolset-msvc:version> is a subfeature.

>   - what is a 'symmetric' feature ?
>

  You can mostly ignore this.  It only
means that when building a target path,
the default value of the feature will
be included.  The primary example of
this is <toolset>.

>   - what is a 'composite' feature ?
>

A composite feature contains other properties:
Ex: <variant>release -> <optimization>on
    <debug-symbols>off <define>NDEBUG

> It would be great to see examples of the above. I promise to try to
> capture my understanding in a document, so this will at least result in
> improved documentation. Please help ! :-)
>

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Stefan Seefeld-2
On 23.12.2016 15:29, Steven Watanabe wrote:

> AMDG
>
> On 12/23/2016 09:05 AM, Stefan Seefeld wrote:
>> Hello,
>>
>> I'm still working on my b2 Python prototype (haven't given up just yet !
>> ;-) ). Instead of reinventing everything from scratch, I'm trying hard
>> to reuse ideas from b2 wherever I can. However, that is quite hard,
>> given the sparseness of its documentation...
>>
>> Right now I'm trying to understand properties and how they propagate
>> from the command-line & jamfiles to targets and actions.
>>
>> So let me outline my understanding of these concepts, combined with a
>> few basic questions I have:
>>
>> * Property sets are sets of properties (duh !). What does the
>> 'PropertySet' class (in build/property_set.py) add over a simple set()
>> (or list()) of property instances ?
>>
>   It's more like a dict than a set.  The main
> benefit is that it mirrors Jam, which makes
> porting jam modules much simpler.  There are
> also some functions specific to properties,
> like target_path or base, free, propagated, etc.

It would be great to understand their purpose, too. ;-)
>> * A Property is a feature with an associated value. What is a LazyProperty ?
>>
> I have no idea, since there's no such thing in Jam.

Ah. The code seems to suggest this is to allow "late" evaluation, as
otherwise a property requires the feature it represents a value for to
exist, which appears to be specific to Python, i.e. this is a constraint
not present in Jam. (I'm basically paraphrasing using my limited
understanding.)

>> * A Feature is a type of a property: it defines certain property
>> attributes, as well as ways to interpret it. Feature values are
>> typically restricted to finite sets of values, unless they are 'free'.
>> What attribute decides whether values are accumulative or exclusive ?
>> (For example, the 'link' value is either 'static' or 'shared', but
>> 'include' is an accumulative set of paths.) Further:
>>
>   Only free features can have multiple values.  In
> retrospect combining 'multiple values' with
> 'values not from a predefined list' was probably
> a mistake.

I was wondering about that indeed. :-)

>   There are a number of cases where
> the correct behavior is 'exactly one path',
> for instance.

yeah, I agree.
>>   - what is a 'sub-feature' ?
>>
>   It's a feature that is only present when another
> property is present:
> Ex: <toolset>msvc-14.0 is actually shorthand for
> <toolset>msvc <toolset-msvc:version>14.0
> where <toolset-msvc:version> is a subfeature.

I see. Thanks.

>>   - what is a 'symmetric' feature ?
>>
>   You can mostly ignore this.  It only
> means that when building a target path,
> the default value of the feature will
> be included.  The primary example of
> this is <toolset>.
>
>>   - what is a 'composite' feature ?
>>
> A composite feature contains other properties:
> Ex: <variant>release -> <optimization>on
>     <debug-symbols>off <define>NDEBUG

So 'variant' is a composite feature whose constituent (sub-)features are
'optimization' etc. ? So 'composite' is the parent of a 'subfeature' ?
>> It would be great to see examples of the above. I promise to try to
>> capture my understanding in a document, so this will at least result in
>> improved documentation. Please help ! :-)
>>
> In Christ,
> Steven Watanabe

How do properties propagate from command-line to (specific) target ? How
are they merged ? (I assume there are rules to obey, such as 'free'
properties can be simply merged, while others are exclusive, requiring
some 'override' rule, etc.
And how are properties combined with conditions ?
Are these mechanisms formally defined somewhere ? A few examples would
be really helpful to illustrate how that works.

Thanks !

        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Aaron Boman
In reply to this post by Stefan Seefeld-2
You're correct about the LazyProperty. The Python port tried to validate some feature before the feature itself existed because the Property class required a valid Feature instance, and would forever mark that Property as a non-erroring sentinel value. The LazyProperty tries to see if the feature has ever been declared and if it does, converts the LazyProperty to a real Property. This is being done to match Jam's functionality.

Aaron

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Steven Watanabe-4
In reply to this post by Stefan Seefeld-2
AMDG

On 12/23/2016 01:44 PM, Stefan Seefeld wrote:
> On 23.12.2016 15:29, Steven Watanabe wrote:
>>
>> A composite feature contains other properties:
>> Ex: <variant>release -> <optimization>on
>>     <debug-symbols>off <define>NDEBUG
>
> So 'variant' is a composite feature whose constituent (sub-)features are
> 'optimization' etc. ? So 'composite' is the parent of a 'subfeature' ?

  The term 'subfeature' means something different.
<optimization> can be used independently
from <variant>.  <variant> just bundles them
for convenience.

>>> It would be great to see examples of the above. I promise to try to
>>> capture my understanding in a document, so this will at least result in
>>> improved documentation. Please help ! :-)
>>>
>
> How do properties propagate from command-line to (specific) target ? How
> are they merged ? (I assume there are rules to obey, such as 'free'
> properties can be simply merged, while others are exclusive, requiring
> some 'override' rule, etc.

  Free features on the command line are applied to
every target.  Non-free features are used to
create a property set which is passed to the
command line targets (The default target being the
current project).  When building a target, you
can determine which value of a feature will win
from the source:
target requirements > build-request > target default-build > feature default
free features always append.  Dependencies are
built using the propagated features of the current target.

lib A : a.cpp ;
exe B : A b.cpp : debug <define>XX ;

$ b2 B release define=YY

B is built with
- <variant>debug (requirements override command line release)
- <define>XX (target requirements)
- <define>YY (command line free feature)
A is built as a dependency of B and gets
- <variant>debug (propagated from B)
- <define>YY (command line free feature)

  In general, b2 --debug-build will explain in
detail which properties are used to build
each target.

> And how are properties combined with conditions ?

  Conditional properties are evaluated when
processing target requirements.  The actual
algorithm evaluates all conditionals repeatedly,
until it reaches a fixed point.

Ex:

rule c ( properties * )
{
  if <variant>debug in $(properties)
  { return <define>DEBUG }
}

Requirements:
<toolset>msvc:<link>shared <link>shared:<variant>debug <conditional>@c

Initial properties:
- <toolset>msvc
Round 1:
- <toolset>msvc <link>shared (Other conditionals are not satisfied)
Round 2:
- <toolset>msvc <link>shared <variant>debug
Round 3:
- <toolset>msvc <link>shared <variant>debug <define>DEBUG
Round 4:
- <toolset>msvc <link>shared <variant>debug <define>DEBUG
(Identical to round 3, terminating the algorithm)

> Are these mechanisms formally defined somewhere ? A few examples would
> be really helpful to illustrate how that works.
>

Try this:
http://www.boost.org/build/doc/html/bbv2/reference/buildprocess.html

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Stefan Seefeld-2
On 23.12.2016 16:39, Steven Watanabe wrote:

> AMDG
>
> On 12/23/2016 01:44 PM, Stefan Seefeld wrote:
>> On 23.12.2016 15:29, Steven Watanabe wrote:
>>> A composite feature contains other properties:
>>> Ex: <variant>release -> <optimization>on
>>>     <debug-symbols>off <define>NDEBUG
>> So 'variant' is a composite feature whose constituent (sub-)features are
>> 'optimization' etc. ? So 'composite' is the parent of a 'subfeature' ?
>   The term 'subfeature' means something different.
> <optimization> can be used independently
> from <variant>.  <variant> just bundles them
> for convenience.

OK. Can you illustrate how subfeatures are used in practice ?

>>>> It would be great to see examples of the above. I promise to try to
>>>> capture my understanding in a document, so this will at least result in
>>>> improved documentation. Please help ! :-)
>>>>
>> How do properties propagate from command-line to (specific) target ? How
>> are they merged ? (I assume there are rules to obey, such as 'free'
>> properties can be simply merged, while others are exclusive, requiring
>> some 'override' rule, etc.
>   Free features on the command line are applied to
> every target.  Non-free features are used to
> create a property set which is passed to the
> command line targets (The default target being the
> current project).  When building a target, you
> can determine which value of a feature will win
> from the source:
> target requirements > build-request > target default-build > feature default
> free features always append.  Dependencies are
> built using the propagated features of the current target.
>
> lib A : a.cpp ;
> exe B : A b.cpp : debug <define>XX ;
>
> $ b2 B release define=YY
>
> B is built with
> - <variant>debug (requirements override command line release)
> - <define>XX (target requirements)
> - <define>YY (command line free feature)
> A is built as a dependency of B and gets
> - <variant>debug (propagated from B)
> - <define>YY (command line free feature)

Great, thanks. So in the above 'debug' will override 'release'. How
would I express "only build B when 'debug' is requested", as opposed to
"override whatever the user asks for" ?

>   In general, b2 --debug-build will explain in
> detail which properties are used to build
> each target.

Thanks, I will try that.

>> And how are properties combined with conditions ?
>   Conditional properties are evaluated when
> processing target requirements.  The actual
> algorithm evaluates all conditionals repeatedly,
> until it reaches a fixed point.
>
> Ex:
>
> rule c ( properties * )
> {
>   if <variant>debug in $(properties)
>   { return <define>DEBUG }
> }
>
> Requirements:
> <toolset>msvc:<link>shared <link>shared:<variant>debug <conditional>@c

(Can you please spell out this line in normal prose ? What does
"<link>shared:" stand for (specifically, what's the meaning of the ':') ?)

> Initial properties:
> - <toolset>msvc
> Round 1:
> - <toolset>msvc <link>shared (Other conditionals are not satisfied)
> Round 2:
> - <toolset>msvc <link>shared <variant>debug
> Round 3:
> - <toolset>msvc <link>shared <variant>debug <define>DEBUG
> Round 4:
> - <toolset>msvc <link>shared <variant>debug <define>DEBUG
> (Identical to round 3, terminating the algorithm)

Thanks. To understand this I need to first understand the meaning of the
initial requirement.
>> Are these mechanisms formally defined somewhere ? A few examples would
>> be really helpful to illustrate how that works.
>>
> Try this:
> http://www.boost.org/build/doc/html/bbv2/reference/buildprocess.html

Yeah, I have read that (more than once), but I interpreting that still
requires quite some guess work, I'm afraid.


> In Christ,
> Steven Watanabe

Many thanks,
        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Steven Watanabe-4
AMDG

On 12/23/2016 02:56 PM, Stefan Seefeld wrote:

> On 23.12.2016 16:39, Steven Watanabe wrote:
>>
>> On 12/23/2016 01:44 PM, Stefan Seefeld wrote:
>>> On 23.12.2016 15:29, Steven Watanabe wrote:
>>>> A composite feature contains other properties:
>>>> Ex: <variant>release -> <optimization>on
>>>>     <debug-symbols>off <define>NDEBUG
>>> So 'variant' is a composite feature whose constituent (sub-)features are
>>> 'optimization' etc. ? So 'composite' is the parent of a 'subfeature' ?
>>   The term 'subfeature' means something different.
>> <optimization> can be used independently
>> from <variant>.  <variant> just bundles them
>> for convenience.
>
> OK. Can you illustrate how subfeatures are used in practice ?

  I thought I did.  The most common use for
subfeatures is the version of a specific
compiler.

>> <snip>
>> lib A : a.cpp ;
>> exe B : A b.cpp : debug <define>XX ;
>>
>> $ b2 B release define=YY
>>
>> B is built with
>> - <variant>debug (requirements override command line release)
>> - <define>XX (target requirements)
>> - <define>YY (command line free feature)
>> A is built as a dependency of B and gets
>> - <variant>debug (propagated from B)
>> - <define>YY (command line free feature)
>
> Great, thanks. So in the above 'debug' will override 'release'. How
> would I express "only build B when 'debug' is requested", as opposed to
> "override whatever the user asks for" ?
>

You have two choices:
- Use a conditional like <variant>release:<build>no
- Add a no-op alternative

exe B : b.cpp : debug ;
alias B ;

  In this case if <variant>debug is present,
then the first alternative will be chosen.
Otherwise, the second will be chosen.

>>   In general, b2 --debug-build will explain in
>> detail which properties are used to build
>> each target.
>
> Thanks, I will try that.
>>> And how are properties combined with conditions ?
>>   Conditional properties are evaluated when
>> processing target requirements.  The actual
>> algorithm evaluates all conditionals repeatedly,
>> until it reaches a fixed point.
>>
>> Ex:
>>
>> rule c ( properties * )
>> {
>>   if <variant>debug in $(properties)
>>   { return <define>DEBUG }
>> }
>>
>> Requirements:
>> <toolset>msvc:<link>shared <link>shared:<variant>debug <conditional>@c
>
> (Can you please spell out this line in normal prose ? What does
> "<link>shared:" stand for (specifically, what's the meaning of the ':') ?)

  The property before the ':' is the condition.  If
those properties are present, then the properties
after the ':' will be included.

>> Initial properties:
>> - <toolset>msvc
>> Round 1:
>> - <toolset>msvc <link>shared (Other conditionals are not satisfied)
>> Round 2:
>> - <toolset>msvc <link>shared <variant>debug
>> Round 3:
>> - <toolset>msvc <link>shared <variant>debug <define>DEBUG
>> Round 4:
>> - <toolset>msvc <link>shared <variant>debug <define>DEBUG
>> (Identical to round 3, terminating the algorithm)
>
> Thanks. To understand this I need to first understand the meaning of the
> initial requirement.

  It's just the initial state when evaluating
conditionals.  It could be anything.  If
you start with <toolset>gcc instead, then
none of the conditionals will match and the
final result will be <toolset>gcc without
any extra properties from the conditionals.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Stefan Seefeld-2
On 23.12.2016 19:24, Steven Watanabe wrote:

> AMDG
>
> On 12/23/2016 02:56 PM, Stefan Seefeld wrote:
>> On 23.12.2016 16:39, Steven Watanabe wrote:
>>> On 12/23/2016 01:44 PM, Stefan Seefeld wrote:
>>>> On 23.12.2016 15:29, Steven Watanabe wrote:
>>>>> A composite feature contains other properties:
>>>>> Ex: <variant>release -> <optimization>on
>>>>>     <debug-symbols>off <define>NDEBUG
>>>> So 'variant' is a composite feature whose constituent (sub-)features are
>>>> 'optimization' etc. ? So 'composite' is the parent of a 'subfeature' ?
>>>   The term 'subfeature' means something different.
>>> <optimization> can be used independently
>>> from <variant>.  <variant> just bundles them
>>> for convenience.
>> OK. Can you illustrate how subfeatures are used in practice ?
>   I thought I did.  The most common use for
> subfeatures is the version of a specific
> compiler.

That much I understood. What I don't understand is how subfeatures are
accessed and used within the build system.

To put this into a somewhat broader context: What I'd like to arrive at
is kind of a "property algebra", i.e. an understanding of the types,
values, and operations that are involved in dealing with properties in
b2. For avoidance of doubt: syntax is only marginally important in this
context, as I'm trying to express these operations in Python. I'd
therefore really like to capture this on a semantic / conceptual level.

>>> <snip>
>>> lib A : a.cpp ;
>>> exe B : A b.cpp : debug <define>XX ;
>>>
>>> $ b2 B release define=YY
>>>
>>> B is built with
>>> - <variant>debug (requirements override command line release)
>>> - <define>XX (target requirements)
>>> - <define>YY (command line free feature)
>>> A is built as a dependency of B and gets
>>> - <variant>debug (propagated from B)
>>> - <define>YY (command line free feature)
>> Great, thanks. So in the above 'debug' will override 'release'. How
>> would I express "only build B when 'debug' is requested", as opposed to
>> "override whatever the user asks for" ?
>>
> You have two choices:
> - Use a conditional like <variant>release:<build>no
> - Add a no-op alternative
>
> exe B : b.cpp : debug ;
> alias B ;
>
>   In this case if <variant>debug is present,
> then the first alternative will be chosen.
> Otherwise, the second will be chosen.

Interesting. Thanks, that's useful.

>>>   In general, b2 --debug-build will explain in
>>> detail which properties are used to build
>>> each target.
>> Thanks, I will try that.
>>>> And how are properties combined with conditions ?
>>>   Conditional properties are evaluated when
>>> processing target requirements.  The actual
>>> algorithm evaluates all conditionals repeatedly,
>>> until it reaches a fixed point.
>>>
>>> Ex:
>>>
>>> rule c ( properties * )
>>> {
>>>   if <variant>debug in $(properties)
>>>   { return <define>DEBUG }
>>> }
>>>
>>> Requirements:
>>> <toolset>msvc:<link>shared <link>shared:<variant>debug <conditional>@c
>> (Can you please spell out this line in normal prose ? What does
>> "<link>shared:" stand for (specifically, what's the meaning of the ':') ?)
>   The property before the ':' is the condition.  If
> those properties are present, then the properties
> after the ':' will be included.

Thanks.

>>> Initial properties:
>>> - <toolset>msvc
>>> Round 1:
>>> - <toolset>msvc <link>shared (Other conditionals are not satisfied)
>>> Round 2:
>>> - <toolset>msvc <link>shared <variant>debug
>>> Round 3:
>>> - <toolset>msvc <link>shared <variant>debug <define>DEBUG
>>> Round 4:
>>> - <toolset>msvc <link>shared <variant>debug <define>DEBUG
>>> (Identical to round 3, terminating the algorithm)
>> Thanks. To understand this I need to first understand the meaning of the
>> initial requirement.
>   It's just the initial state when evaluating
> conditionals.  It could be anything.  If
> you start with <toolset>gcc instead, then
> none of the conditionals will match and the
> final result will be <toolset>gcc without
> any extra properties from the conditionals.

Excellent, I think I understand the above logic now.

I still have a few follow-up questions, though:

* how are properties merged / propagated ? For example, what operation
is responsible to merge "<include>foo" to an existing property set (and
where would a conflict be caught if instead I used "<link>wrong" or
"<link>static <link>shared" or somesuch ?

* OK, I think this is enough for now, so I'll try to implement /
document what I understand so far. :-)

Thanks so much for your help, that's much appreciated !

        Stefan


--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Stefan Seefeld-2
In reply to this post by Steven Watanabe-4
Hi,

I'm still trying to understand features and properties...

On 23.12.2016 19:24, Steven Watanabe wrote:
>
>>>   In general, b2 --debug-build will explain in
>>> detail which properties are used to build
>>> each target.
>> Thanks, I will try that.

I have tried `--debug-build`, but not got any (additional) output
whatsoever. I have then used `-dN` with different values for N (much
larger than '2', which I use regularly), which produced so much output
that I could hardly get any information out of it. (I suppose that's
more a tool for developers that already understand the internals and
simply want to debug.)

So I'm asking again: what is the best way to trace properties as they
are defined, passed around, merged, and applied to build actions ?


What I'm in particular trying to understand is the merge process. As far
as I understand, a typical target has two property-sets associated with
it, called 'build-requirements' and 'usage-requirements'.
'Usage-requirements' of a prerequisite target are somehow merged into
the 'build-requirements' of a dependent target, but exactly how isn't
yet clear to me (d.h., what role the different feature attributes play
is still a bit of a mystery). Is there any document that provides a
listing of that, and is there some code that implements that merge
process that I could look at (perhaps even run unit-tests against ?)



Thanks,
        Stefan


--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Steven Watanabe-4
AMDG

On 01/03/2017 08:31 PM, Stefan Seefeld wrote:

> I'm still trying to understand features and properties...
>
> On 23.12.2016 19:24, Steven Watanabe wrote:
>>
>>>>   In general, b2 --debug-build will explain in
>>>> detail which properties are used to build
>>>> each target.
>>> Thanks, I will try that.
>
> I have tried `--debug-build`, but not got any (additional) output

My mistake.  It's --debug-building.

> <snip>
>
> What I'm in particular trying to understand is the merge process. As far
> as I understand, a typical target has two property-sets associated with
> it, called 'build-requirements' and 'usage-requirements'.
> 'Usage-requirements' of a prerequisite target are somehow merged into
> the 'build-requirements' of a dependent target, but exactly how isn't
> yet clear to me (d.h., what role the different feature attributes play
> is still a bit of a mystery).

Usage requirements are added very late,
and can only use free features.

> Is there any document that provides a
> listing of that, and is there some code that implements that merge
> process that I could look at (perhaps even run unit-tests against ?)
>

Property merging is implemented in property.refine.
There are some tests at the end of property.jam.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Stefan Seefeld-2
On 03.01.2017 22:44, Steven Watanabe wrote:

> AMDG
>
> On 01/03/2017 08:31 PM, Stefan Seefeld wrote:
>> I'm still trying to understand features and properties...
>>
>> On 23.12.2016 19:24, Steven Watanabe wrote:
>>>>>   In general, b2 --debug-build will explain in
>>>>> detail which properties are used to build
>>>>> each target.
>>>> Thanks, I will try that.
>> I have tried `--debug-build`, but not got any (additional) output
> My mistake.  It's --debug-building.

That works, thanks !
However, it looks a bit incomplete to me. Consider this:

  lib l : l.cpp : <link>shared ;
  exe hello : hello.cpp l ;


(I'd like to trace how the fact that 'l' is compiled as a shared lib
results in the 'l.cpp' source to be compiled with -fPIC.
While I can see the 'setup-fpic' rule in 'gcc.jam' taking care of this
in the code, I'd like to understand the flow of information in more
formal terms, i.e. the properties of 'l' affecting the properties of
'l.o'. But the --debug-building flag doesn't even report the 'l.o'
target at all. It looks like the 'l' target is considered a black box.

Is there a way to trace the generator logic, i.e. see how a toolset is
picked based on the property set, and how the 'inner' targets are
generated ?


Thanks,
        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Steven Watanabe-4
AMDG

On 01/13/2017 10:39 AM, Stefan Seefeld wrote:
>
> Is there a way to trace the generator logic, i.e. see how a toolset is
> picked based on the property set, and how the 'inner' targets are
> generated ?
>

That would be --debug-generators.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Stefan Seefeld-2
On 13.01.2017 13:48, Steven Watanabe wrote:
> AMDG
>
> On 01/13/2017 10:39 AM, Stefan Seefeld wrote:
>> Is there a way to trace the generator logic, i.e. see how a toolset is
>> picked based on the property set, and how the 'inner' targets are
>> generated ?
>>
> That would be --debug-generators.

Nice, thanks ! (It would be even better if all these flags were
available via `b2 -h` !)


Thanks,

        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Steven Watanabe-4
AMDG

On 01/13/2017 11:59 AM, Stefan Seefeld wrote:

> On 13.01.2017 13:48, Steven Watanabe wrote:
>>
>> On 01/13/2017 10:39 AM, Stefan Seefeld wrote:
>>> Is there a way to trace the generator logic, i.e. see how a toolset is
>>> picked based on the property set, and how the 'inner' targets are
>>> generated ?
>>>
>> That would be --debug-generators.
>
> Nice, thanks ! (It would be even better if all these flags were
> available via `b2 -h` !)
>

  They're shown by --help.  (It's somewhat
unfortunate, but -h and --help are different.)

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Stefan Seefeld-2
On 13.01.2017 14:19, Steven Watanabe wrote:

> AMDG
>
> On 01/13/2017 11:59 AM, Stefan Seefeld wrote:
>> On 13.01.2017 13:48, Steven Watanabe wrote:
>>> On 01/13/2017 10:39 AM, Stefan Seefeld wrote:
>>>> Is there a way to trace the generator logic, i.e. see how a toolset is
>>>> picked based on the property set, and how the 'inner' targets are
>>>> generated ?
>>>>
>>> That would be --debug-generators.
>> Nice, thanks ! (It would be even better if all these flags were
>> available via `b2 -h` !)
>>
>   They're shown by --help.  (It's somewhat
> unfortunate, but -h and --help are different.)


Indeed. But even more unfortunate: `bjam --help` shows strictly nothing
for me. Or rather, it seems the option is ignored, so I get

$ bjam --help
...found 12 targets...


('bjam' is the tool's name on Fedora 25, coming from the boost-jam-1.60
package)

Is the `--help` flag newer than 1.60 ? (In my boost repo, I can of
course reproduce that `b2 --help` reports all those options.)

    Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Steven Watanabe-4
AMDG

On 01/13/2017 12:24 PM, Stefan Seefeld wrote:

>
> Indeed. But even more unfortunate: `bjam --help` shows strictly nothing
> for me. Or rather, it seems the option is ignored, so I get
>
> $ bjam --help
> ...found 12 targets...
>
>
> ('bjam' is the tool's name on Fedora 25, coming from the boost-jam-1.60
> package)
>
> Is the `--help` flag newer than 1.60 ? (In my boost repo, I can of
> course reproduce that `b2 --help` reports all those options.)
>

  It's always existed.  Let me check whether I can
reproduce this.

In Christ,
Steven Watanabe


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature, properties, variants, and all the rest

Steven Watanabe-4
In reply to this post by Stefan Seefeld-2
AMDG

On 01/13/2017 12:24 PM, Stefan Seefeld wrote:
>
> ('bjam' is the tool's name on Fedora 25, coming from the boost-jam-1.60
> package)
>
> Is the `--help` flag newer than 1.60 ? (In my boost repo, I can of
> course reproduce that `b2 --help` reports all those options.)
>

  The boost-build package on Fedora is
missing options/help.jam.  The reason for
this appears to be that it's skipped by the
install script for Boost.Build.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Loading...