Re: [Qbs] Evaluation of Conditional Depends

[Christian Kandeler]

On Wed, 10 Jun 2020 11:37:02 +0200 (CEST)
"Richard Weickelt"  wrote:

> ... And module properties set in the profile. I had a glance look at the 
> source code. When evaluating the condition property, we are taking the 
> following information from the product context into account:
> 
> - module values set in the profile (can even be a local profile within the 
> product item)
> - a fully(?) resolved instance of the qbs module
> 
> The result is then cached since this module might be loaded multiple times in 
> the same product context. I don't see why we could not allow access to 
> product as well as project properties and module properties set in the 
> product item.
> 
> Christian, is that restriction by purpose?

Well, there was no use case so far, and it does seem a bit dubious at first 
glance. But if there's a compelling case, perhaps it could be added (if it is 
actually possible; it's been a while since I've done work in that area).


Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Evaluation of Conditional Depends

[Richard Weickelt]

> And of course the module's own properties set in the module file, except
> those referring to probes. But we do evaluate the module condition in a
> product context. Is that not the real product context or at least very
> close? E.g. if product sets moduleX.propA to true and depends on moduleX,
> is propA then not true when evaluating the condition? At least that was my
> expectation in my previous reply. Also, doesn't it make sense to provide
> access to custom product properties in that phase?

... And module properties set in the profile. I had a glance look at the source 
code. When evaluating the condition property, we are taking the following 
information from the product context into account:

- module values set in the profile (can even be a local profile within the 
product item)
- a fully(?) resolved instance of the qbs module

The result is then cached since this module might be loaded multiple times in 
the same product context. I don't see why we could not allow access to product 
as well as project properties and module properties set in the product item.

Christian, is that restriction by purpose?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Evaluation of Conditional Depends

[Richard Weickelt]

Christian Kandeler wrote on 10. June 2020 10:09 (GMT +02:00):

> On Tue, 9 Jun 2020 20:55:43 +0200
> Christian Gudrian  wrote:
> 
>> Could it be that only a restricted set of variables is available during
>> evaluation of the module’s „condition“ property? Neither
>> „product“ nor any imported modules’ variables can be accessed
>> („Can’t find variable“ error).
>> 
>> Is that a known limitation or am I doing something wrong?
> 
> Remember that the module has not been loaded yet, so the right-hand side
> of the condition property is rather restricted in terms of what you can
> access there. Basically, it's just the qbs module.

And of course the module's own properties set in the module file, except those 
referring to probes. But we do evaluate the module condition in a product 
context. Is that not the real product context or at least very close? E.g. if 
product sets moduleX.propA to true and depends on moduleX, is propA then not 
true when evaluating the condition? At least that was my expectation in my 
previous reply. Also, doesn't it make sense to provide access to custom product 
properties in that phase?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Evaluation of Conditional Depends

[Christian Kandeler]

On Tue, 9 Jun 2020 20:55:43 +0200
Christian Gudrian  wrote:

> Could it be that only a restricted set of variables is available during 
> evaluation of the module’s „condition“ property? Neither „product“ nor any 
> imported modules’ variables can be accessed („Can’t find variable“ error).
> 
> Is that a known limitation or am I doing something wrong?

Remember that the module has not been loaded yet, so the right-hand side of the 
condition property is rather restricted in terms of what you can access there. 
Basically, it's just the qbs module.


Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Evaluation of Conditional Depends

[Christian Gudrian]

Hello, again!

Richard Weickelt wrote:

> You need to add a expression in the modules' condition that evaluates to true 
> only for one module variant.

Could it be that only a restricted set of variables is available during 
evaluation of the module’s „condition“ property? Neither „product“ nor any 
imported modules’ variables can be accessed („Can’t find variable“ error).

Is that a known limitation or am I doing something wrong?

Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Evaluation of Conditional Depends

[Richard Weickelt]

Christian Gudrian wrote on 7. June 2020 10:48 (GMT +02:00):

> 

> I’ve put a simple example project on GitHub:
> https://github.com/cgudrian/QbsConfigurationDemo
> .
> 
> I am trying to implement basic Qbs support for the RT operating system
> ChibiOS (https://www.chibios.org ). It supports
> a wide range of hardware platforms and peripheral components and is highly
> configurable. The OS is statically linked into the finally binary.
> Specific Hardware support can be enabled and disabled at will.
> 
> The example code I have published tries to mimic the original source code
> layout and „supports“ two types of peripheral components: ADC and CAN.
> Each peripheral component consists of a generic, abstract part in the OS
> and a corresponding (low level) driver implementation which might come in
> different versions depending on the specific board the build is targeting.
> 
> What I would like to end up with is the following:
> 
> RTOSApplication {
>   RTOS.enableADC: true
>   Depends { name: "boards.Board1“ }
>   file: "main.c"
> }
> 
> Qbs has to
>   - include the needed source files both for the OS and the driver
>   - set the appropriate compiler defines
>   - set the appropriate include paths
> 
> Currently the board modules depend on the concrete drivers modules
> conditionally. By using this design the list properties (sourceFiles,
> defines, includePaths) automatically get appended to instead of replaced.
> And it is exactly these conditional dependencies that do not work.
> 
> The modules A, B and C from my original post map to the modules in my
> example as follows:
> 
> ModuleA -> RTOS
> ModuleB -> board.Board1, board.Board2
> ModuleC -> driver.adc.v1, driver.adc.v2, driver.can.v1

You are setting values of the RTOS Module in the product. But I think module 
values from there do not populate when loading other modules unless you set 
them in the module itself (set Rtos.enableAdc in the board module). You may 
either:

1. Make enableAdc & friends a property of RtosApplication and use 
product.enableAdc in the conditional Depends item because product properties do 
populate.

2. Make enableAdc a property of the board module and set this one in your 
application.

Something you might not be aware of: Qbs can handle multiple module variants in 
the same folder. You need to add a expression in the modules' condition that 
evaluates to true only for one module variant. That is how the cpp module does 
it with toolchainType. The variants could even be located in different 
locations in the fs as long as the folder structure is the same and all module 
subtrees are in qbsSearchPaths. 

That way you could have a single board module with x variants and a single ADC 
driver module with different versions in separate files. You would then set for 
instance board.type in your application and the board module would set 
add.version. You may use inheritance for sharing property definitions. This is 
not so obvious, thus study the cpp module. I think this would simplify your 
module structure a lot. 

Richard
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Evaluation of Conditional Depends

[Christian Gudrian]

Hello!

> Could you clarify the relationship between ModuleA and ModuleB? Maybe post
> some minimal example code.

I’ve put a simple example project on GitHub: 
https://github.com/cgudrian/QbsConfigurationDemo 
.

I am trying to implement basic Qbs support for the RT operating system ChibiOS 
(https://www.chibios.org ). It supports a wide range 
of hardware platforms and peripheral components and is highly configurable. The 
OS is statically linked into the finally binary. Specific Hardware support can 
be enabled and disabled at will.

The example code I have published tries to mimic the original source code 
layout and „supports“ two types of peripheral components: ADC and CAN. Each 
peripheral component consists of a generic, abstract part in the OS and a 
corresponding (low level) driver implementation which might come in different 
versions depending on the specific board the build is targeting.

What I would like to end up with is the following:

RTOSApplication {
RTOS.enableADC: true
Depends { name: "boards.Board1“ }
file: "main.c"
}

Qbs has to
- include the needed source files both for the OS and the driver
- set the appropriate compiler defines
- set the appropriate include paths

Currently the board modules depend on the concrete drivers modules 
conditionally. By using this design the list properties (sourceFiles, defines, 
includePaths) automatically get appended to instead of replaced. And it is 
exactly these conditional dependencies that do not work.

The modules A, B and C from my original post map to the modules in my example 
as follows:

ModuleA -> RTOS
ModuleB -> board.Board1, board.Board2
ModuleC -> driver.adc.v1, driver.adc.v2, driver.can.v1


Thanks!

Christian

___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Evaluation of Conditional Depends

[Christian Gagneraud]

On Sun, 7 Jun 2020 at 04:30, Christian Gudrian  wrote:
>
> Hello!
>
> In ModuleA there is a property enableFeature which by default is false.
>
> ModuleB conditionally depends on ModuleC, if ModuleA.enableFeature is true.
>
> A Product depends on ModuleA and ModuleB and sets ModuleA.enableFeature to 
> true. However, ModuleC is not used as a dependency.

That looks like a weird scenario, maybe this means that the
enableFeature property is not in the right place.
Can't you move it to the top project, and pull it in Module A & B?
Or maybe proxy the property in module B, e.g. your product assigns the
same value to ModuleA.enableFeature and ModuleB.enableSameFeature?

Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Evaluation of Conditional Depends

[Richard Weickelt]

> In ModuleA there is a property enableFeature which by default is false.
> 
> ModuleB conditionally depends on ModuleC, if ModuleA.enableFeature is true.
> 
> A Product depends on ModuleA and ModuleB and sets ModuleA.enableFeature to 
> true. However, ModuleC is not used as a dependency.

Could you clarify the relationship between ModuleA and ModuleB? Maybe post
some minimal example code.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] Evaluation of Conditional Depends

[Christian Gudrian]

Hello!

In ModuleA there is a property enableFeature which by default is false.

ModuleB conditionally depends on ModuleC, if ModuleA.enableFeature is true.

A Product depends on ModuleA and ModuleB and sets ModuleA.enableFeature to 
true. However, ModuleC is not used as a dependency.

I assume this is expected behaviour, because otherwise it might be impossible 
to reach a stable dependency graph. But how can I achieve what I’m trying to do 
here?

Thanks!

Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs