[QBS] propagate compiler options

[Marcel Mulder]

> On 16 Jan 2015, at 09:27, Richard Weickelt <richard at weickelt.de> wrote:
> 
> This is only a very specific use-case. What, if there is no single "main"
> product, but many products in a "main" project item? Think of the ABC
> example I've given in a prevous message. This would likely cause conflicts.
> 
> What You might want is, to set module options and flags in the root project,
> that are taken as default for the modules in dependent projects/products.
> You can achieve that already with toolchain profiles very easily. But with
> the drawback that toolchain profiles are bound to the machine qbs is running
> on and not the source files. And this of course is not acceptable when
> developing/building/testing/deploying on different machines.
> 

I don’t think it is a special use case I am talking about. Probably I am not clear about how I see it.
A project exists of one or more products. Each top-level product defines a set of options and flags,
because you do not define this in the project item. The product uses “sub”-products. Those product should be build with the same base off options and flags. If you don’t do that you can end up with a mixture of object files and libraries. For example one with debug options and no optimisation and another build for speed without debug information. Of course it should be able to override options lower in the build hierarchy.

The idea of putting it in the toolchain profile is not an option for the reason you are mentioning. 
But I also work a lot with QT-Creator and here I can’t do all the setting I want.

> The export item works the other way round. It exports module options e.g.
> cpp include paths to dependent products. This is very important when using
> libraries.
> 

This is exactly the reason why I propose it. You export the files needed to be build to the top-level product. Like it does with the include paths, which I already use.

> If You think, that this is a good idea, then You could submit a feature
> request to https://bugreports.qt.io

May be I will, but I want to understand the qbs filosofie. The thoughts behind it. Maybe I don’t
see the things as you guys are doing because of lack of knowledge.

> 
> It's not redundant. References are on project level. Dependencies are on
> product level.

You are totally right about that. But as Andrii mentioned there is a link between references and dependencies. Sometimes if you have to add/remove/change something you have to do it twice.
This is what I want to prevent if I am coding, therefore I want to prevent this also in build files.

Kind Regards,

Marcel