[QBS] propagate compiler options

[Richard Weickelt]

> 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. 

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.

> 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. 

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.

> If some qbs developer
> can confirm that this is a good idea then I am willing to help with the
> implementation.

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

> 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 ;-)

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

Kindest Regards
Richard