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 <anpi...@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.mul...@xs4all.nl
> <mailto:marcel.mul...@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@qt-project.org <mailto:QBS@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
> Skype: anpilogov.andrey
> mailto:anpi...@gmail.com <mailto:anpi...@gmail.com>,
> andrii.anpilo...@mesheven.com <mailto:andrii.anpilo...@mesheven.com>
>
_______________________________________________
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs
