[QBS] propagate compiler options

[Richard Weickelt]

Hi Marcel,

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

Again: What You describe would work fine with:
    Top-Level-A requires Lib-C
    Top-Level-B requires Lib-D

But requires double building of Lib-C with:
    Top-Level-A requires Lib-C
    Top-Level-B requires Lib-C

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

It looks like building with different profiles would be an appropriate
solution here. You could prepend the qbs build process by Your own shell
script and set all compiler flags via command line from within this script.
This way You can detach compiler options from the toolchain profile and keep
them along with Your project sources. Does that help?

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

The current export item exports module properties to dependent products
only. If You want to export source files, then You can not speak of a
product any more. It sounds more like an externally-defined group item that
is then imported into a product. This could probably work with the current
qbs, but You'd have to find a way to set the filepaths correctly.

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

I struggled with similar problems a few monts ago and have used qbs for a
likely similar use-case, that's why I'm replying in this thread. I'm not a
qbs developer, so I leave the philosphical questions up to them. One
possible way to understand qbs could be, to use it the way it is currently
supposed to work. Search for other projects in the web, that use qbs and
study them.

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

If You want to get Your things done in a reasonable amount of time, it's
often necessary to simply copy-paste instead of elaborate on a sophisticated
generic solution. If You want to talk about philosophy, this is part of my
personal epiphany ;-)