[QBS] Proposal: improvements to the config system

[devtomsci at me.com]

Hi Jörg,

> Yes exactly. I think its a good idea to mirror the module / property
> hierarchy below the config key "default". So everything below "default"
> must be a module name and everything a level further down is the default
> value for the property of the same name in the corresponding module.
> Example: to set the default value for qbs.toolchain one could do
> qbs config --global default.qbs.toolchain myToolChain
 
We could use "modules" instead of "default"? That makes it a bit more consistant with how we refer to them from within embedded javascript code (eg product.modules.qbs.targetOS) and contrasts well with the other top-level groups being "platforms" and "profiles" which are things not belonging to a module. It also avoids confusion with the existing use of "defaults", although maybe we don't need to worry too much about being compatible with a 0.1 release :) I'm not totally sold on it though, so if you prefer default that's fine with me. Maybe something really verbose like "moduledefaults" to make it absolutely clear it's only for modules and only contains default values?

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.

> This one uses ini files that can be generated by scripts / tools. Our
> probe tools of course could just use a QSettings object as well. But
> having them editable in your favourite text editor turned out useful.

We could support a qbs import/export command for converting from/to plaintext format. Or even a "qbs editconfig" that pops up a text editor like how "hg commit" works. I can imagine that while setting things up having everything not just platforms editable in one place would be pretty handy.

> So having two things, platform and profile, sounds right to me.
>
> > How about this - in the global config:
> [...]
>
> That looks really good!
> This way we're getting rid of the extra location of platform configs and
> have everything in one place.
 
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>
defaults.buildvariant: map to modules.qbs.buildVariant (note the mismatch in capitalisation, at least in the source I'm looking at)
defaults.useColoredOutput: Maybe this could move to top level? Or into the qbs module?
defaults.jobs: ditto?

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

> I'm fine with profile even if the association ".pro file" has some weird
> taste. ;-)
 
That hadn't occurred to me :)

> I mean I'd be happy if you can be persuaded to implement stuff. :)
 
I see - yes it would seem rude not to after taking up so much space on the list :)

Cheers,

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20120327/f67e2006/attachment.html>