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 <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 Thanks! Christian
_______________________________________________ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
