[QBS] Proposal: improvements to the config system

[Joerg Bornemann]

Hi Tom,

> 1) Have the "qbs config" command-line use dot-separated properties just
> like the property syntax on the command-line and inside qbs files,
> rather than slashes.
> For example instead of "qbs config defaults/platform" you'd say "qbs
> config defaults.platform". (Although as per (2) I propose this
> particular item is replaced by "qbs.platform" instead).

+1
This would be much more consistent.

> 2) All properties should use the same fully-qualified name wherever they
> are accessed

For the defaults I agree. They should match their property names.
But if they are not under a special key like default.qbs.platform or so 
you loose the ability to configure different Qt versions or other 
hierarchical settings.

> 2c) Properties in submodules should be referrable to using the syntax
> module.submodule.property even in .qbs files

+1

> 3) Rework how the "qt" config group and qtcore module properties work
>
> The "qt" group in qbs config is a slightly special case because it
> doesn't map directly onto a module, and rather it defines a set of
> configurations for the qtcore module. So it's not possible to make use
> of the automatic propagation of config keys to module properties I
> proposed above. There are 2 possibilities that occur to me:
>
> Either....
> 3a) Continue with qt/qtVersionName/settings
>
> This would be largely the same structure and qtcore.qbs file as now,
> although I think "defaults/qtVersionName" should move to "qt.configName"
> or somesuch:
> qt.configName: "x64" // If undef, assume "default"
> qt.default.path: "D:\QtSDK-1.1\Desktop\Qt\4.7.2\mingw"
> qt.x64.path: "D:\QtSDK-1.1\QtSources\4.7.2-msvc2010-x64"

But this would try to set stuff for the qt submodules "configName", 
"default" and "x64" right?

> ... or ...
> 3b) Take the proposed alias support and make it generic enough to
> support setting the Qt config using it

Your profiles look a lot like the platform configurations. These are 
currently ini files (should change to .qbs, json or such) and can be 
found in a folder that "qbs platforms print-config-base-dir" prints.
They contain settings that are directly mapped to properties.
Usually they set the properties for toolchain, targetOS and alike.
So maybe it would even be possible to use them for this purpose.

> 4) qbs should support a mode whereby all the calculated properties are
> dumped out

+10 ;-)

> * Does this sound like a good idea, and something we'd want in qbs?
> * Go with (3a) or (3b)? 3b seems to me to be the more elegant and
> powerful solution

How about doing both? Keep the config values and pimp the platform.

> I could even be persuaded to implement some of it if people
> are in favour :-)

We're getting back to this! ;-)


Cheers,

Jörg