[QBS] Aliases in QBS - first prototype

[Oswald Buddenhagen]

On Fri, Feb 17, 2012 at 02:16:03PM +0100, Storm-Olsen Marius (Nokia-MP/Austin) wrote:
> On 17/02/2012 04:55, ext Oswald Buddenhagen wrote:
> > anyway, i must say that i don't like the whole idea at all. using
> > command line aliases to define build configurations is completely
> > backwards.
> 
> Not necessarily to _define_ build configurations, but perhaps to easily 
> allow you to repeat builds you do quite often.
>
which is actually exactly the same.

> Take Bogdans' build for multiple hosts at the same time, often.
> 
i'm not sure, but i think you misunderstand his use case. iiuc, android
executables are like macx universal binaries, only that the magic to do
that is not built into the compiler. even if this is not so, we need
multiple arches within *one* build of a project lastest when creating a
package.

> Being able to say
>      qbs buildall-arm
> for example, would make it simpler for him, and many others I'm sure.
> 
> Sure you can always argue, 'you can just make a 1-line shell script for 
> that!'. So could you for git as well, yet aliases are there, and I 
> already have plenty of them. It's useful.
> 
i think the use case is *a tad* different. in git you are really
configuring commands. here you are configuring option sets.

> > here's an alternative idea. i haven't really thought it through:
> >
> > # just use built-in debug config
> > $ qbs debug
> >
> > # clone debug config, alter a property
> > $ qbs debug optimization:"fast"
> 
> Why does this one clone 'debug', and not just use debug config and add 
> optimization:"fast"?
> 
because then it would not be saved. the current build would have no
inherent indication of what it actually *is*.

> What does it clone the built-in configuration to?
> 
i already wrote that. to the project's local settings.

though it may indeed make sense to have per-user global configs, as
well. let's prefix them with % when creating and explicitly referencing
(shouldn't conflict with shells unless somebody has some really stupidly
named env variables under windows).

> > # mofify the existing cloned config
> > $ qbs debug targetArch:"arm7hl"
> 
> ..and this one modifies an already cloned config? Which one is it 
> modifying by the way? 'debug' or some other cloned config?
> 
of course it's this project's local "debug". why should it be anything
else? the cloning is a simple shadowing like you know it from all kinds
of other configuration systems.

> What happens if you now use 'debug' in some other project? Does it also 
> get targetArch:"arm7h1", since you clone a shadow 'debug'?
> 
no, because it's local.

> > # start from scratch and alter again
> > $ qbs @debug targetArch:"arm7hl"
> 
> huh? '@' prefix is a magical what? 'reclone configuration'?
>
no, "reference built-in configuration".

> So in this case,
>      reclone built-in 'debug' to 'debug' and change
>      targetArch to "arm7h1"?
> 
yes

> So then this is shorthand for recloning a built-in, which there are how 
> many of?
>
names are unique within a given domain (built-in, user, local).

> Do we need a separate syntax for recloning built-ins verses 
> non-built-ins?
> 
yes, because the more local ones shadow more global ones and you still
need a way to access the more global ones.

> > opinions?
> 
> Yes, I'd say, add some simple alias functionality, letting people create 
> their own complex command-lines right now, and let's wait on the 
> configuration manipulation once we have configuration nodes support, and 
> have a greater grasp of those things.
>
i don't like that approach, because whatever we add now will stick. we had
enough of that with qmake already. i'm a big fan of the python motto:
there is one correct way to do something.