[QBS] Aliases in QBS - first prototype

[marius.storm-olsen at nokia.com]

On 17/02/2012 04:55, ext Oswald Buddenhagen wrote:
> On Fri, Feb 17, 2012 at 11:09:40AM +0100, ext Tomasz Siekierda
> wrote:
>> This is because my commit looks for aliases in config, and then
>> simply replaces them in "args" string list with values from
>> configuration.
>>
> this is a rather fragile approach. you have no protection against
> multiple expansions (and you can't even really take advantage of
> that either, because the expansion order is pretty arbitrary,
> depending on how the keys fall out of the config).
>
> 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. Take Bogdans' build for 
multiple hosts at the same time, often.

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.


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

What does it clone the built-in configuration to?

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

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

> # start from scratch and alter again
> $ qbs @debug targetArch:"arm7hl"

huh? '@' prefix is a magical what? 'reclone configuration'?
So in this case,
     reclone built-in 'debug' to 'debug' and change
     targetArch to "arm7h1"?

So then this is shorthand for recloning a built-in, which there are how 
many of? Do we need a separate syntax for recloning built-ins verses 
non-built-ins?

/me barfs a little in his mouth :)

> # don't shadow the built-in config, derive from the built-in
> $ qbs armdebug=@debug targetArch:"arm7hl"
 >
> # use our private config again
> $ qbs armdebug
>
> # dispose of our build config
> $ qbs armdebug=
>
> the build configurations are saved within the chosen build dir, along
> with the build graph, cached configure results and everything else.
> i chose to shadow the built-ins by default so that the user is not
> forced to think about managing build configs if he just wants a single
> one (presumably the common case).
>
> the next step would be defining meta configs:
> $ qbs fancy=@debug+armrelease
>
> 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 the above syntax atm.

-- 
.marius