| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Now unqualified variables are project-private and can be typified.
|
|
Now it should be possible to use `[]` for wildcard patterns, for example:
foo = foo.[hit]xx
Note that a leading bracket expression will still be recognized as attributes
and escaping or quoting it will inhibit pattern matching. To resolve this case
we need to specify an empty attribute list:
foo = [] [abc]-foo.cxx
|
|
Now we can do:
$ b config.cxx.coptions=-O3 config.cxx.coptions=-O0
Or even:
$ b config.cxx.coptions=-O3 config.cxx.coptions+=-g
|
|
Currently, if we say:
$ b dir/ ./foo=bar
The scope the foo=bar is set on is relative to CWD, not dir/. While this
may seem wrong at first, this is the least surprising behavior when we
take into account that there can be multiple dir/'s.
Sometimes, however, we do want the override directory to be treated relative
to (every) target's base scope that we are building. To support this we are
extending the '.' and '..' special directory names (which are still resolved
relative to CWD) with '...', which means "relative to the base scope of every
target in the buildspec". For example:
$ b dir/ .../foo=bar
Is equivalent to:
$ b dir/ dir/foo=bar
And:
$ b liba/ libb/ .../tests/foo=bar
Is equivalent to:
$ b liba/ libb/ liba/tests/foo=bar libb/tests/foo=bar
|
|
Before:
$ b dir/:foo=bar ...
After:
$ b dir/foo=bar
Alternatively (the buildfile syntax):
$ b 'dir/ foo=bar'
Note that the (rarely used) scope visibility modifier now leads to a
double slash:
$ b dir//foo=bar
|
|
|
|
|
|
|
