[QBS] propagate compiler options

[Thomas Epting]

> property stringList myIncludePaths: [ path ]
> But I read in the mail list that using path is deprecated.
> What is the future way to go? Using sourceDirectory?

Even though "path" is deprecated now, its functionalitiy will available in
the future. You just have to migrate to whatever the coming Qbs versions
will provide as a replacement.

> 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.
> [...] Mostly they are configuration dependenties.

So I would try merging all these configuration dependencies in one place,
and let A, B and C depend on them. A very simple approach would be to
introduce a common product, which exports the configuration stuff.

--- RTOS.qbs ---
import qbs 1.0
Product {
    Export {
        Depends { name: "cpp" }
        cpp.includePaths: ...
        cpp.defines: ...
    }
}

Now let A, B and C depend on RTOS. You can even consider adding project
level properties in the exported stuff (haven't tried this, but I think it
should work). Or, consider Richards approach, which also sounds very good.

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

Of course it has to be done the other way round. The generic product has to
provide a solution, and you have to adopt to it. So your RTOS could define
a set of properties which it expects to be available at project level (e.g.
rtosIncludePaths, rtosDefines, rtosCxxFlags, ...). They can even check if
these properties exist and react accordingly, e.g. by using JavaScript like
if (project.rtosDefines === undefined).

> What if you have application A which is depending on static
> library B. Now you have a define in your code and in the
> library code to disalbe a certain feature like: [...]

You could either depend both A and B on a common product like Features.qbs,
which exports the defines you need. Or, define the features on project
level and let A and B query them. Here's a sketch for the latter:

--- Project.qbs ---
import qbs 1.0
Project {
    property bool hasFeatureA: true
    property bool hasFeatureB: false
}

--- A.qbs ---
import qbs 1.0
Application {
    Depends { name: "cpp" }
    cpp.defines: {
        var defs = [ ]
        if (!project.hasFeatureA)
            defs.push("DISABLE_FEATURE_A")
        ...
        return defs
    }
}

--- B.qbs ---
import qbs 1.0
StaticLibary {
    Depends { name: "cpp" }
    cpp.defines: {
        var defs = [ ]
        if (!project.hasFeatureA)
            defs.push("DISABLE_FEATURE_A")
        ...
        return defs
    }
}

Regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20150118/2eba3e67/attachment.html>