[QBS] Aliases in QBS - first prototype

Oswald Buddenhagen oswald.buddenhagen at nokia.com
Fri Feb 17 11:55:29 CET 2012


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.

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"

# mofify the existing cloned config
$ qbs debug targetArch:"arm7hl"

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

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



More information about the Qbs mailing list