[QBS] propagate compiler options

[Richard Weickelt]

> 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.