[QBS] propagate compiler options

[Marcel Mulder]

Hi all,

I have a working setup now using the idea with the RTOS.qbs and using project properties to propagate the compiler options. But I don’t really like it.
Suggestions of using batch or script files are good for a temporarily solutions but it is not really an option if you want to become a serious build system. All administration to build a system should be in the qbs files. The only thing you want to define on the command line is what should be build and what to use for the build and a few build options or variants. I also use QT creator a lot and don’t want to customise stuff there. 

I hope the qbs developers find a way of propagating compiler settings and defines and also think of way to deal with cross dependencies. Maybe via inheritance or via access to the top level product via the project property. Because I think that using javascript and start coding in a build system for simple things every build system can do is very strange and unwanted. Qbs is clean and I like it. Lets keep it that way ;-)
I want to participate and give my input because I have ideas how to implement it neatly. But I got the feeling it is not very welcome.

I want to thank Thomas, Andrii and Richard for there input. That was very valuable!

Best regards, Marcel


> On 18 Jan 2015, at 11:02, Thomas Epting <thomas.epting.stryker at gmail.com> wrote:
> 
> > 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/20150119/9a34347b/attachment.html>