> On 16 Jan 2015, at 09:27, Richard Weickelt <rich...@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

_______________________________________________
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Reply via email to