[QBS] propagate compiler options
Marcel Mulder
marcel.mulder at xs4all.nl
Thu Jan 15 20:46:35 CET 2015
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 <mailto: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 <mailto: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 <mailto: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 <mailto:QBS at qt-project.org>
>> http://lists.qt-project.org/mailman/listinfo/qbs <http://lists.qt-project.org/mailman/listinfo/qbs>
>>
>>
>>
>> --
>> --
>> WBR,
>> Andrii Anpilogov
>> Phone: +86 186-1660-3720 <tel:%2B86%20186-1660-3720>
>> Skype: anpilogov.andrey
>> mailto:anpilog at gmail.com <mailto:anpilog at gmail.com>, andrii.anpilogov at mesheven.com <mailto:andrii.anpilogov at mesheven.com>
>>
>
>
>
>
> --
> --
> WBR,
> Andrii Anpilogov
> Phone: +86 186-1660-3720
> Skype: anpilogov.andrey
> mailto:anpilog at gmail.com <mailto:anpilog at gmail.com>, andrii.anpilogov at mesheven.com <mailto:andrii.anpilogov at mesheven.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20150115/ad1e0c3a/attachment.html>
More information about the Qbs
mailing list