[QBS] Proposal: improvements to the config system

[Joerg Bornemann]

On 27/03/2012 20:28, ext devtomsci at me.com wrote:

> We could use "modules" instead of "default"?

Yeah sure. That's also how the product configuration looks like if 
you're writing rules (product.modules.cpp.defines etc) so it would be 
just consistent. :)

> We'd probably want qbs config to disallow setting any key not starting
> with profiles, modules/default, or platforms to avoid people
> accidentally setting keys they think should have an effect (like
> "qbs.toolchain"). Or maybe assume modules.* (or modules.qbs.* if
> appropriate) and/or print a warning.

Sounds sensible.

> Great, sounds good to me too. If we were to go with using "modules" for
> setting module values we would have a keyspace for qbs config of:
>
> modules.<modulename>.<defaultvalue>
> platforms.<platformname>.<modulename>.<value>
> profiles.<profilename>.<modulename>.<value>
> profile: <comma separated list of default profiles>
>
> And for legacy support we could accept (but maybe warn about):
>
> defaults.platform: map to modules.qbs.platform
> defaults.qtVersionName: map to the profile key
> qt.<name>.<key>: map to profiles.<name>.qt.core.<key>

Looks good!

> defaults.buildvariant: map to modules.qbs.buildVariant (note the
> mismatch in capitalisation, at least in the source I'm looking at)

Ah oh well that is most probably unused (because undocumented). :)

> defaults.useColoredOutput: Maybe this could move to top level? Or into
> the qbs module?
> defaults.jobs: ditto?

These are settings that affect the behaviour of the command line 
application and are not visible in project files / modules. So maybe 
these must go into another config category like... I don't know... 
"preferences"? OTOH it maybe doesn't hurt to have those settings in the 
base module.

> With the same open question on whether we refer to properties in
> qtcore.qbs as qt.* or qt.core.*

I'd favour qt.core.*



BR,

Jörg