[QBS] propagate compiler options
Dmitry Volosnykh
dmitry.volosnykh at gmail.com
Wed Jan 21 20:05:54 CET 2015
Nice solution, Marcel! I will take a note of it.
On Wed, Jan 21, 2015 at 9:46 PM, Marcel Mulder <marcel.mulder at xs4all.nl>
wrote:
> Hi,
>
> I want to let you know what my final setup is. The RTOS.qbs example made
> be think about the compiler flags. So my project file now looks like this:
>
> import qbs 1.0
>
>
> Project {
>
> references: [
>
> "wsbd-app.qbs",
>
> "ccflags.qbs",
>
> "includes.qbs",
>
> "board.qbs",
>
> "hal.qbs",
>
> "kernel.qbs",
>
> ]
>
> }
>
>
> In the ccflags.qbs I have all my compiler settings. Something like:
>
> import qbs 1.0
>
>
> Product {
>
> name: "ccflags"
>
> Export {
>
> Depends { name: 'cpp' }
>
> cpp.commonCompilerFlags: [
>
> "-mcpu=cortex-m4","-mthumb","-mabi=aapcs","-mfloat-abi=hard","-mfpu=fpv4-sp-d16",
>
> "-std=gnu99",
>
> "-fomit-frame-pointer","-falign-functions=16","-fdata-sections","-ffunction-sections","-fno-common",
>
> "-Wstrict-prototypes"
>
> ]
>
> cpp.linkerFlags:[
>
> "-mthumb", "-mabi=aapcs",
>
> "-Los/ports/GCC/ARMCMx",
>
> "-TSTM32F429xI.ld",
>
> "-mcpu=cortex-m4","-mthumb","-mabi=aapcs","-mfloat-abi=hard","-mfpu=fpv4-sp-d16",
>
> "-Wl,--gc-sections","--specs=nano.specs","-nostartfiles",
>
> ]
>
> cpp.defines: [
>
> "THUMB",
>
> ]
>
> cpp.warningLevel: "all" //"all" // or "none", "default"
>
> cpp.treatWarningsAsErrors: true
>
> cpp.positionIndependentCode: false
>
>
> Properties {
>
> condition: qbs.buildVariant === "debug"
>
> cpp.debugInformation: true
>
> cpp.optimization: "none"
>
> }
>
> Properties {
>
> condition: qbs.buildVariant === "release"
>
> cpp.debugInformation: false
>
> cpp.optimization: "small"
>
> }
>
> }
>
> }
>
>
> The include.qbs is similar for all include paths. Now also the other
> product depend on this, like:
>
> import qbs 1.0
>
>
> Product {
>
> type: "application"
>
> name: “example"
>
>
> Depends { name: "cpp" }
>
> Depends { name: "kernel" }
>
> Depends { name: "hal" }
>
> Depends { name: "board" }
>
> Depends { name: "ccflags" }
>
> Depends { name: "includes" }
>
>
> cpp.embedInfoPlist : false // Mac OS X work arround
>
> cpp.executableSuffix: ".out"
>
> files: [
>
> "main.c", "usbcfg.c",
>
> ]
>
> }
>
>
> This works great and has no cross dependencies. The only thing thats bothering me, is that the compiler flags are now a product.
>
> Thats not something I thought of when I started this project. And I think I am not the only one.
>
> There is one tiny thing I do not understand. In my main product about I have the line:
>
> cpp.executableSuffix: ".out"
>
> If I have that line in de ccflags.qbs than the output file will be .a
> instead of .out. So he is ignoring the line in de ccflags.qbs but all other
> flags are used.
> Something I do not comprehend.
>
> Anyway. I am happy with my setup.
>
> Best regards, Marcel
>
> On 19 Jan 2015, at 18:17, Marcel Mulder <marcel.mulder at xs4all.nl> wrote:
>
> 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
>
>
> _______________________________________________
> QBS mailing list
> QBS at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs
>
>
>
> _______________________________________________
> QBS mailing list
> QBS at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20150121/144d2f0d/attachment.html>
More information about the Qbs
mailing list