[QBS] propagate compiler options

Andrii Anpilogov anpilog at gmail.com
Thu Jan 15 04:43:11 CET 2015


Hi Marcel,

It looks like qbs is designed to prevent one product influence others in a
wide way 8(
I really miss that after Makefiles...

> The only thing I actually want is the I can add files to my product from
external products, like an OS.

Theoretically you can do it with Export item. I'm thinking about this
approach instead of linking Products as static libraries is some cases.

P/S:
I really unlike fact we have to provide Project references and Depeds items
twice. It sounds extremely inconvenient.

Regards.


2015-01-15 3:30 GMT+08:00 Marcel Mulder <marcel.mulder at xs4all.nl>:

> Hi Andrii,
>
> Not completely but I like your setup.
> I don’t want to make kernel.qbs dependent on MarcelToolchain. The qbs
> files from the real time OS are used in several projects, not only in my
> project. The other projects also have other hardware target. Meaning
> completely different compiler options. The only thing I actually want is
> the I can add files to my product from external products, like an OS.
> I will experiment some what more but I think the only solution is to add
> this kind of functionality to the qbs code.
>
> Many thanks for your input however. It is inspiring.
>
> Regards, Marcel
>
> On 14 Jan 2015, at 05:49, Andrii Anpilogov <anpilog at gmail.com> wrote:
>
> Hi Marcel,
>
> I could be wrong but isn't it what you are looking for?
> Define custom toolchain specific Product and reuse it in all your Products:
> --------------------------------------------------------
> MarcelToolchaine.qbs
> import qbs
> Product {
>
>             Depends { name: "cpp" }
>
>         cpp.defines: [“THUMB" ]
>
>         cpp.warningLevel: "all"
>
>         cpp.treatWarningsAsErrors: true
>
>         cpp.positionIndependentCode: false
>
>         cpp.commonCompilerFlags: [
>
>             "-mcpu=cortex-m4","-mthumb","-mabi=aapcs","-mfloat-abi=hard","-mfpu=fpv4-sp-d16",
>
>             "-std=gnu99","-flto","-fno-builtin",
>
>             "-fdata-sections","-ffunction-sections",
>
>         ]
>
>         cpp.includePaths: [ "." ]
>
> }
> --------------------------------------------------------
>
> --------------------------------------------------------
> Kernel,qbs:
> import qbs
>
> MarcelToolchain {
>   files: [ "*.cpp", "*.h"]
> }
> --------------------------------------------------------
>
> --------------------------------------------------------
> YourEmbeddedProject:
>
> Project {
>
>     references: [
>
>         "kernel/kernel.qbs"
>
>     ]
>
>
>     MarcelToolchaine{
>
>         type: "application"
>
>         name: “example"
>
>
>             Depends { name: "kernel" }
>
>                 files: [ “main.c" ]
>
>     }
>
> }
>
> --------------------------------------------------------
>
>
> You also can defile your custom Module:
> import qbs 1.0
> qbs_search_path/modules/MarcelToolchain/MarcelToolchain.qbs:
> Module {
>         Depends { name: "cpp" }
>
>         cpp.defines: [“THUMB" ]
>
>         cpp.warningLevel: "all"
>
>         cpp.treatWarningsAsErrors: true
>
>         cpp.positionIndependentCode: false
>
>         cpp.commonCompilerFlags: [
>
>             "-mcpu=cortex-m4","-mthumb","-mabi=aapcs","-mfloat-abi=hard","-mfpu=fpv4-sp-d16",
>
>             "-std=gnu99","-flto","-fno-builtin",
>
>             "-fdata-sections","-ffunction-sections",
>
>         ]
>
> }
>
> Then kernel.qbs and YourEmbeddedProject.qbs will look like this:
> --------------------------------------------------------
> Kernel,qbs:
> import qbs
>
> Product {
> Depends { name: "MarcelToolchain" }
>   files: [ "*.cpp", "*.h"]
> }
> --------------------------------------------------------
>
> --------------------------------------------------------
> YourEmbeddedProject.qbs:
>
> Project {
>
>     references: [
>
>         "kernel/kernel.qbs"
>
>     ]
>
>
>     Product{
>
>         type: "application"
>
>         name: “example"
>
>
>             Depends { name: "kernel" }
>
>             Depends { name: "MarcelToolchain" }
>
>                 files: [ “main.c" ]
>
>     }
>
> }
>
> --------------------------------------------------------
>
>
> 2015-01-14 2:46 GMT+08:00 Marcel Mulder <marcel.mulder at xs4all.nl>:
>
>> >
>> > Am I getting You right, that You want to set some toolchain options in a
>> > product and all parent products should be build with the same options?
>> Even
>> > though that makes sense in Your case, think about the following example
>> > which is not uncommon:
>> >
>> > Product A depends on product C
>> > Product B depends also on product C.
>> >
>> > Let's assume product C defines some default toolchain options. When
>> product
>> > A defines its own toolchain flags and product B does that as well, what
>> > would happen with the options in product C? You can not simply override
>> them
>> > with the options of a dependent product A/B. Product C would have to be
>> > build twice - with different options for A and B. But QBS builds every
>> > product exactly once during a build procedure.
>> >
>> > A straight forward solution for the above scenario would be, to define
>> all
>> > common toolchain options in the toolchain profile.
>> >
>>
>> No, you don’t get it right. I want to propagate down, not up. So the
>> parent product determines the compile options of the siblings.
>> In your case Product A defines the compile options for Product C when
>> building A and Product B defines the compile option for Product C when
>> building B.
>> Do you know how I can do that? Because when a build for example product A
>> than product C is build with the cpp module defaults and not with the
>> compile options of product A.
>> Product C should however be able to override or add compile options.
>>
>> >
>> >> It is actually strange that something simple like
>> >> compile options can’t be propagated or that files can be simply added
>> to
>> >> the files: [] list. For example like:
>> >>
>> >> Export { files: [ foo.c ] }
>> >>
>> >> I tried to look into the code and add it myself, but I have to take
>> more
>> >> time to understand the structure of the abs sources.
>> >
>> > What exactly are You going to achieve with that?
>> >
>>
>> What I want to achieve is what I described above. When it can’t be done
>> with the current implementation of qbs it should be added because I think
>> that this is core functionality.
>> With qmake I use .pri file to achieve the same and with make files people
>> do it all the time. At least in my world, the embedded one.
>>
>> Regards, Marcel
>>
>>
>> _______________________________________________
>> QBS mailing list
>> QBS at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/qbs
>>
>
>
>
> --
> --
> WBR,
>   Andrii Anpilogov
>   Phone: +86 186-1660-3720
>   Skype: anpilogov.andrey
>   mailto:anpilog at gmail.com, andrii.anpilogov at mesheven.com
>
>
>


-- 
-- 
WBR,
  Andrii Anpilogov
  Phone: +86 186-1660-3720
  Skype: anpilogov.andrey
  mailto:anpilog at gmail.com, andrii.anpilogov at mesheven.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20150115/eb88da89/attachment.html>


More information about the Qbs mailing list