[QBS] Proposal: improvements to the config system

[devtomsci at me.com]

Hi Jörg,

> 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.

You can always override qbs.whatever on the command line (or with a profile or pimped up platform config) so I don't think there's anything wrong with being able to directly set <root>.qbs.whatever in the global config if you really want to. Granted you probably wouldn't want to, and you'd use a platform or profile to set qbs.whatever instead, but the concept of having the config keyspace mirror the module+property layout pretty much requires this to be permitted, otherwise it sort of stops making sense. Since we already have a heirarchy of ways by which a key's value can be overridden (command line overrides local config, local config overrides global config, global config overrides the qbs file) it makes sense (to me at least!) that the default fallback value for a key is located at "qbs.whatever" in the lowest level in the heirarchy (ie the global config). I don't see why it should be in a different location at that level, or that it prevents anything else from being possible? What I mean is, it's the default by virtue of being defined in the global config, so it doesn't need to be tagged in any other way in addition to that.

> > 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?
> > ... 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.
 
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?

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.

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.

How about this - in the global config:

platforms.mingw32.targetOS: "windows"
platforms.mingw32.toolchain: "mingw"
platforms.mingw32.cpp.toolchainInstallPath: "D:\QtSDK-1.1\mingw\bin"

platforms.msvc2010.targetOS: "windows"
platforms.msvc2010.toolchain: "msvc"
platforms.msvc2010.cpp.toolchainInstallPath:"C:\Program Files (x86)\Microsoft Visual Studio 10.0"
platforms.msvc2010.cpp.windowsSDKPath=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A

profile: "myDefaultSetup"
profiles.myDefaultSetup.qt.core.path: "D:\QtSDK-1.1\Desktop\Qt\4.7.2\mingw"
profiles.myDefaultSetup.qbs.platform: "mingw32"
profiles.myDefaultSetup.qbs.architecture: "x86"
profiles.x64.qt.core.path: "D:\QtSDK-1.1\QtSources\4.7.2-msvc2010-x64"
profiles.x64.qbs.platform: "msvc2010"
profiles.x64.qbs.architecture: "x86_64"

And in a local config (for a project that has a fooDir property for specifying an external dependency if libFoo support should be compiled in) I might have in addition:
profiles.libFoo.project.fooDir: "D:\hg\libfoo\build"

And then I could write
qbs build release profile:libFoo,x64

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.
> > 4) qbs should support a mode whereby all the calculated properties are
> > dumped out
>
> +10 ;-)

hehe :)
> > 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?

Cheers,

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