[QBS] Proposal: improvements to the config system

[Joerg Bornemann]

Hi Tom,

>> > 3) Rework how the "qt" config group and qtcore module properties work
>> >
>> > Either....
>> > 3a) Continue with qt/qtVersionName/settings
>> > 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?
>
> Yeah good point, if we're doing (2b) then I guess we'd need to change
> the key to make it clear we're not setting stuff directly on the qt
> module - maybe call it qtconfig or something. Hmm. Makes me think that
> this approach isn't really a good compromise and we should go the whole
> hog with profiles/super platforms instead.
>
> I guess this also means we're saying that anything else we define at the
> top level (like profiles, or platforms below) can and will never be a
> module name... Is this what you meant about using "default.qbs.platform"
> above?

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


> Hmm haven't come across those, thanks for the link. Is there a reason
> why they aren't in the same QSettings as the qbs global config?

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.

> I think we should definitely try to unify profiles and platform
> configurations one way or another because they do seem to be doing very
> similar things. The question is, is there a strong reason for having the
> platform configs in separate files in the appdata dir (or wherever
> print-config-base-dir is on other platforms)? If not, it would simplify
> things to move them into the same heirarchy as the global config, at
> which point they're looking pretty similar to the profiles proposal.

No there's no strong reason. As long as tools can easily write it I'm 
fine with unifying it. The probe tools could also just call "qbs config" 
without knowing anything about the internal format.

> Although, maybe you'd want to keep the qt config out of the platform
> config? Because you could well have multiple versions of Qt using the
> same toolchain and you wouldn't want to replicate all the toolchain
> settings in every platform? Also I wouldn't want to accidentally nuke my
> customised platform setup by rerunning "qbs platforms probe". So maybe
> there's room to have both - after all I may want some local profiles
> specific to my project, but I wouldn't want them visible to other
> projects and allowing local platform configurations seems a somewhat odd
> thing to encourage. Also specifying more than one platform for a given
> buildVariant is stretching the metaphor a bit far, whereas having
> multiple profiles (or a profile plus a platform) is something I'd
> conceivably want to do.

You definitely want to reuse the properties that have been set in 
platform configs. 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.

> and setup everything I want. Although that sounds like a profiler is
> involved, sigh. Maybe call them something else... "config" would be ok
> if not for the confusion with the "qbs config" command - "qbs config
> --global config:myDefaultSetup" looks a bit odd.

I'm fine with profile even if the association ".pro file" has some weird 
taste. ;-)

>> > I could even be persuaded to implement some of it if people
>> > are in favour :-)
>>
>> We're getting back to this! ;-)
>
> What do you mean?

I mean I'd be happy if you can be persuaded to implement stuff. :)


Cheers,

Jörg