| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There are three options here: we can "fall through" to an outer scope (there
is always the global scope backstop; this is the old semantics, sort of), we
can return NULL straight away, or we can fail. It feels like in most cases
unknown scope or target is a mistake and doing anything other than failing is
just making things harder to debug.
|
|
|
|
Now unqualified variables are project-private and can be typified.
|
|
|
|
Explicit target{} should be used instead. Also, in this context, absent target
type is now treated as file{} rather than target{}, for consistency with all
other cases.
|
|
This is in addition to the already supported path-based target type/pattern
specific variables. For example:
hxx{*}: x = y # path-based
hxx{~/.*/}: x = y # regex-based
|
|
|
|
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
|
|
For example:
$ b x+=1 x=2 x+=3
Should result in '2 3', not '1 2 3'.
|
|
|
|
For example, now instead of:
lib{foo}: cxx.loptions += -static
lib{foo}: cxx.libs += -lpthread
We can write:
lib{foo}:
{
cxx.loptions += -static
cxx.libs += -lpthread
}
The same works for prerequisites as well as target type/patterns. For
example:
exe{*.test}:
{
test = true
install = false
}
|
|
Now instead of:
./: exe{foo}
exe{foo}: cxx{*}
We can write:
./: exe{foo}: cxx{*}
Or even:
./: exe{foo}: libue{foo}: cxx{*}
This can be combined with prerequisite-specific variables (which naturally
only apply to the last set of prerequisites in the chain):
./: exe{foo}: libue{foo}: bin.whole = false
|
|
|
|
|
|
|
|
|
|
|
|
Now instead of:
dir{foo/bar/}
We get:
foo/dir{bar/}
Which feels more consistent with how we print other names/targets. That is,
"directory bar/ in directory foo/" similar how foo/exe{bar} is "executable
bar in directory foo/".
|
|
|
|
In essence, if the buildfile is:
./: */
Then it can be omitted entirely (provided there is at least one subdirectory).
|
|
|
|
|
|
|
|
Currently, we only propagate types of sole, unquoted expansions (variable,
function call, or eval context), similar to NULL. To untypify the value,
simply quote it.
|
|
For example:
x = [uint64] 1
x = a # Ok.
|
|
So these three are equivalent:
*: foo = 1
{*}: foo = 2
*{*}: foo = 3
|
|
|
|
The 'projects and subprojects' semantics resulted in some counter-intuitive
behavior. For example, in a project with tests/ as a subproject if one builds
one of the tests directly with a non-global override (say C++ compiler), then
the main project would be built without the overrides. I this light,
overriding in the whole amalgamation seems like the right thing to do. The
old behavior can still be obtained with scope qualification, for example:
b ./:foo=bar
|
|
Semantically, these are similar to variable overrides and are essentially
treated as "templates" that are applied on lookup to the "stem" value that is
specific to the target type/name. For example:
x = [string] a
file{f*}: x =+ b
sub/:
{
file{*}: x += c
print $(file{foo}:x) # abc
print $(file{bar}:x) # ac
}
|
|
|
|
|
|
For example:
if ($x == [null])
Or:
if ([uint64] 01 == [uint64] 1)
|
|
|
|
|
|
For example:
print $(dir/:var)
print $(file{target}:var)
print $(dir/file{target}:var)
Note that if the scope/target does not (yet) exists, it will be created.
|
|
For example:
v = [null]
v = [string] abc
v += ABC # abcABC
|
|
Now we can do:
[string] str = foo
|
|
|
|
|
|
|
|
For example:
cxx{*-options}: dist = true
1. Only single '*' wildcard is supported, matches 0 or more characters.
2. If target type is not specified, it defaults to any target.
3. Appending (+=) is not allowed.
4. The value is expanded immediately in the context of the scope.
5. The more specific pattern (i.e., with the shortest "stem") is preferred.
If the stem has the same length, then the last defined (but not redefined)
pattern is used. This will probably have to change to become an error.
See tests/variable/type-pattern for more examples.
|
|
For now it acts as just the value mode that can be enabled anywhere
variable expansion is supported, for example:
(foo=bar):
And the primary use currently is to enable/test quoted and indirect
variable expansion:
"foo bar" = FOO BAR
print $"foo bar" # Invalid.
print $("foo bar") # Yeah, baby.
foo = FOO
FOO = foo
print $($foo)
Not that you should do something like this...
|
|
|
|
|
