[Qbs] Evaluation of Conditional Depends

Richard Weickelt richard at weickelt.de
Sun Jun 7 11:48:24 CEST 2020



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
> <https://github.com/cgudrian/QbsConfigurationDemo>.
> 
> I am trying to implement basic Qbs support for the RT operating system
> ChibiOS (https://www.chibios.org <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


More information about the Qbs mailing list