> I have for example application A which depend on static library B and C. > Static library B depends on static library C. No problem yet but now > static library C depends on B. Now we have a problem because of creating > a loop. This is however not uncommon. Most RTOSes will have such kind of > dependencies. Not dependent on code but depended on header files. E.g.:
I have a similar scenario containing an 'application' product, a 'core' lib and multiple 'platform' libs (and many more). 'Platform' can not compile without core, but 'core' can not compile without some header files from 'platform'. So I've defined a pseudo-product 'plattform-headers' just exporting the essential include paths. 'Core' now needs a dependency to 'platform-headers' in order to compile, but no one to 'platform'. The 'platform' product has a dependency to 'core'. That's it. All platforms are referenced in a qbs project (file). The correct reference is determined by the qbs.architecture property. // meta-platform qbs file Project { property var platform_packages : { return { platform1: ["platform1/platform1.qbs"], platform2: ["platform2/platform2.qbs"], // ... }; } references: { var platform = qbs.architecture; if (!(platform in platform_packages)) { throw "Could not find packages for platform " + platform; } return (platform_packages[platform]); } } The application project file needs to reference the platform meta project and the application product just needs a dependency to 'platform' (and other products). > De kernel depends on the board configuration and the board configuration > is depending on the kernel. Mostly they are configuration dependenties. > An RTOS exist of several modules like kernel, hal, ports, compiler > configuration, linker files, board files, processor target files. They > all have a relationship with each other. The end result should however be > defined in the top level application. I can have 20 different > applications using a different set of compiler, processor, board, memory > configuration etc. So it must be defined at top level. You could specify Your own QBS module items to transport such configuration options. These can be set either in toolchain profiles or on command line. Every product that needs something configured has to depend on such a module. You can use shell script wrappers that call qbs with all module properties specifies on command line in order to keep the profiles clean and the configuration options together with the source files. > The property as you proposed is a nice solution with the current > implementation of qbs. The drawback is that independent projects like a > RTOS, or libraries supporting qbs have to also support my naming > convention of the properties. This is kind of strange that a library > project is dependent of a user project file. This does not work in the > real world. Or You go with Thomas' proposal. I've done that as well and it works fine in my small world. I don't see any problem if You define Your own project item type and use those types for every application project. This way You can ensure that every property is at least initialized with default values. If You come up with another nice solution, please share it. _______________________________________________ QBS mailing list QBS@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs