| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
}
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The inclusion/exclusion is controlled via the 'include' prerequisite-specific
variable. Valid values are:
false - exclude
true - include
adhoc - include but treat as an ad hoc input
For example:
lib{foo}: cxx{win32-utility}: include = ($cxx.targe.class == 'windows')
exe{bar}: libs{plugin}: include = adhoc
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This meta operation can be used to print basic information (name, version,
source/output roots, etc) for one or more projects.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The original semantics turned out to be too restrictive. For example, the
user may have specified the config.c variable on the command line that is
only used by an imported project that is loaded in a subsequent generation.
We are also relaxing it for values since conceptually the two feel the same.
For a value the (hypothetical) example is a "common" variable set in a project
root that is only queried in a subdirectory in a subsequent generation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The semantics is similar to the C++11 range-based for:
list = 1 2 3
for i: $list
print $i
Note that there is no scoping of any kind for the loop variable ('i' in
the above example).
See tests/loop/for.test for some examples/ideas.
In the future the plan is to also support more general while-loop as well
as break and continue.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
