[QBS] propagate compiler options

Andrii Anpilogov anpilog at gmail.com
Fri Jan 16 04:16:01 CET 2015


Hi,

I think I see where it comes from...
I really miss only two things:
1) Be able to add reference from Product to another product.
2) Be able to transparently pass exported settings through dependency chain.

Regards

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

> Hi Andrii,
>
> I don’t understand why they made it in such a way. You want to make a
> product using other products but the “main" product decides for which
> platform and with which configuration it is build.
> It would be nice if it can be done with an Export item. When using an
> export item you can have for example a test main.c file in the product. You
> export the common/shared files and not the test main.c file. Or other files
> not relevant if you don’t use the product stand alone.
> If some qbs developer can confirm that this is a good idea then I am
> willing to help with the implementation.
>
> The double reference/Depend stuf is also a thing I don’t understand and is
> in my opinion redundant. And as you say; inconvenient. As a programmer I
> never want to do things twice ;-)
>
> Regards, Marcel
>
>
> On 15 Jan 2015, at 04:43, Andrii Anpilogov <anpilog at gmail.com> wrote:
>
> 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
>
>
>


-- 
-- 
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/20150116/fbc6d343/attachment.html>


More information about the Qbs mailing list