[QBS] v2 of Proposal: improvements to the config system

[Tom Sutcliffe]

I'm not sure we need to get this complicated do we? Profiles are already (planned to be) composable, so you can layer them on top of each other on the command line. So for Andre's example we could have:

profiles.x64.qt.core.path: "D:\QtSDK-1.1\QtSources\4.7.2-msvc2010-x64"
profiles.x64.qt.foo1: ...
[...]
profiles.x64.qt.foo63: ...
profiles.x64.qbs.platform: "msvc2010"
profiles.x64.qbs.architecture: "x86_64"
profiles.x64.qbs.buildVariant: "release"

profiles.a.buildVariant: "release-ish"


And you could say
qbs profile:x64
qbs profile:x64,a

and the buildVariant in "a" would override the one in "x64" because it appears later on the command-line, and you haven't had to duplicate any of the keys in the common x64 config. It seems like it would complicate the concept quite a bit just to be able to say "profile:x64a" rather than "profile:x64,a"? I was hoping we could get away with keeping profiles as simple as possible.

Regards,

Tom

On 29 Mar, 2012,at 08:08 AM, joerg.bornemann at nokia.com wrote:

> The number of Qt properties needed for a valid Qt version setup ranges between one and seven at the moment. In the worst case you'll have to set binPath, incPath, libPath, mkspecsPath, version, qtNamespace and qtLibInfix. Potentially this will get more, like the defines (that are written to qconfig.pri) and a property that specifies if its a static Qt etc...
> Like the platform properties, this is something you don't want to replicate in every profile but just reference the Qt version by name.
>
> For every config key in a profile we must answer the question "is it a property value or a reference to another config value". Maybe like this
> profiles.foo.qt: "myqt"
> does not have subkeys - thus we pull in qt.myqt.*
> And
> profiles.foo.bar.someprop: "narf"
> has subkeys below profiles.foo.bar. Then bar must be a module with the property someprop which we set to "narf".
>
>
> BR,
>
> Jörg
> ________________________________________
> From: qbs-bounces+joerg.bornemann=nokia.com at qt-project.org [qbs-bounces+joerg.bornemann=nokia.com at qt-project.org] on behalf of ext André Pönitz [andre.poenitz at mathematik.tu-chemnitz.de]
> Sent: 28 March 2012 23:44
> To: Tom Sutcliffe
> Cc: qbs at qt-project.org
> Subject: Re: [QBS] v2 of Proposal: improvements to the config system
>
> On Wed, Mar 28, 2012 at 08:20:40PM +0000, Tom Sutcliffe wrote:
> > The way we'd represent this in the QSettings keyspace would be
> > something like this. I've modelled this on my setup where for a given
> > qt version I need to set the architecture and platform at the same
> > time - with this proposal these can be setup in exactly the same way.
> >
> > 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"
> > profiles.x64.qbs.buildVariant: "release"
>
> > Which profile(s) are used is determined by the top-level "profile"
> > key. Thus you could run "qbs build release profile:x64" (or just "qbs
> > profile:x64") then all the keys under profiles.x64 would be set (ie
> > qbs.platform would be set to "msvc2010" etc), or you could set the
> > default value for this (and thus the default profile to be used) by
> > calling "qbs config --global profile myDefaultSetup".
>
> Sorry for being late in the game (and for not knowing qbs, getting
> terminology wrong, ...)
>
> I think it might be beneficial to have one more indirection below the
> "profiles" level, depending on you many properties hide behind e.g. the
> 'qt.' "component"
>
> If there will be "a lot qt. properties" like
>
> profiles.x64.qt.core.path: "D:\QtSDK-1.1\QtSources\4.7.2-msvc2010-x64"
> profiles.x64.qt.foo1: ...
> [...]
> profiles.x64.qt.foo63: ...
> profiles.x64.qbs.platform: "msvc2010"
> profiles.x64.qbs.architecture: "x86_64"
> profiles.x64.qbs.buildVariant: "release"
>
> profiles.x64a.qt.core.path: "D:\QtSDK-1.1\QtSources\4.7.2-msvc2010-x64"
> profiles.x64a.qt.foo1: ...
> [...]
> profiles.x64a.qt.foo63: ...
> profiles.x64a.qbs.platform: "msvc2010"
> profiles.x64a.qbs.architecture: "x86_64"
> profiles.x64a.qbs.buildVariant: "release-ish"
>
> this could be
>
> qt.somename64.core.path: "D:\QtSDK-1.1\QtSources\4.7.2-msvc2010-x64"
> qt.somename64.foo1: ...
> [...]
> qt.somename64.foo63: ...
>
> profiles.x64.qt: "somename64" # "links" to all qt.somename64.*
> profiles.x64.qbs.architecture: "x86_64"
> profiles.x64.qbs.buildVariant: "release"
>
> profiles.x64a.qt: "somename64"
> profiles.x64a.qbs.architecture: "x86_64"
> profiles.x64a.qbs.buildVariant: "release-ish"
>
> It's essentially the same data, but treats profiles as a "bag of
> highlevel components" instead of a "bag of all the properties of
> highlevel components", and would incidentally pretty much match
> what (hopefully, work is on-going...) will be the internal layout
> of qt versions, toolchains, etc for Qt Creator 2.6
>
> I pretty much agree with everything else.
>
> Andre'
>
>
> _______________________________________________
> QBS mailing list
> QBS at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20120329/fad2724e/attachment.html>