| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This can now be achieved with the new `recipe` directive:
recipe <language> <file>
Note that similar to the use of if-else and switch directives with recipes,
this directive requires explicit % recipe header. For example, instead of:
file{foo.output}:
{{
echo 'hello' >$path($>)
}}
We can now write:
file{foo.output}:
%
recipe buildscript hello.buildscript
With hello.buildscript containing:
echo 'hello' >$path($>)
Similarly, for C++ recipes (this time for a pattern), instead of:
[rule_name=hello] file{~'/(.+)\.output/'}:
% update clean
{{ c++ 1 --
--
...
}}
We can now write:
[rule_name=hello] file{~'/(.+)\.output/'}:
% update clean
recipe c++ hello.cxx
With hello.cxx containing:
// c++ 1 --
--
...
Relative <file> paths are resolved using the buildfile directory that contains
the `recipe` directive as a base.
Note also that this mechanism can be used in exported buildfiles with recipe
files placed into build/export/ together with buildfiles.
|
|
This attribute can be used to disable the default target semantics for the
sources/imported buildfile.
|
|
|
|
|
|
|
|
|
|
x [...], for x [...])
|
|
|
|
|
|
|
|
|
|
|
|
This is in preparation for (again) not treating primary member of an
ad hoc group as a group for variable lookup.
|
|
Now instead of ignoring imported stuff (which turned out to be racy), we only
consider conditions up to the include boundary. The thinking here is that an
included (but not sourced) buildfile is a standalone entity (e.g., imported
project but also could be just a side-included buildfile).
Note that unfortunately we will still be issuing warnings in imported projects
since there is no straightforward way to know what is being distributed and
what is not while parsing.
|
|
|
|
|
|
These options can be used to understand which dependency chain causes matching
or execution of a particular target.
|
|
|
|
|
|
|
|
A rule hint is a target attribute, for example:
[rule_hint=cxx] exe{hello}: c{hello}
Rule hints can be used to resolve ambiguity when multiple rules match the same
target as well as to override an unambiguous match.
|
|
|
|
|
|
This variable allows a project to distinguish between development and
consumption builds. While normally there is no distinction between these two
modes, sometimes a project may need to provide additional functionality during
development. For example, a source code generator which uses its own generated
code in its implementation may need to provide a bootstrap step from the
pre-generated code. Normally, such a step is only needed during development.
See "Project Configuration" in the manual for details.
|
|
|
|
|
|
An ad hoc pattern rule consists of a pattern that mimics a dependency
declaration followed by one or more recipes. For example:
exe{~'/(.*)/'}: cxx{~'/\1/'}
{{
$cxx.path -o $path($>) $path($<[0])
}}
If a pattern matches a dependency declaration of a target, then the recipe is
used to perform the corresponding operation on this target. For example, the
following dependency declaration matches the above pattern which means the
rule's recipe will be used to update this target:
exe{hello}: cxx{hello}
While the following declarations do not match the above pattern:
exe{hello}: c{hello} # Type mismatch.
exe{hello}: cxx{howdy} # Name mismatch.
On the left hand side of `:` in the pattern we can have a single target or an
ad hoc target group. The single target or the first (primary) ad hoc group
member must be a regex pattern (~). The rest of the ad hoc group members can
be patterns or substitutions (^). For example:
<exe{~'/(.*)/'} file{^'/\1.map/'}>: cxx{~'/\1/'}
{{
$cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0])
}}
On the left hand side of `:` in the pattern we have prerequisites which can
be patterns, substitutions, or non-patterns. For example:
<exe{~'/(.*)/'} file{^'/\1.map/'}>: cxx{~'/\1/'} hxx{^'/\1/'} hxx{common}
{{
$cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0])
}}
Substitutions on the left hand side of `:` and substitutions and non-patterns
on the right hand side are added to the dependency declaration. For example,
given the above rule and dependency declaration, the effective dependency is
going to be:
<exe{hello} file{hello.map>: cxx{hello} hxx{hello} hxx{common}
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
depdeb preamble
|
|
Before the block used to apply to the set of prerequisites before the last
`:`. This turned out to be counterintuitive and not very useful since
prerequisite-specific variables are a lot less common than target specific.
And it doesn't fit with ad hoc recipes.
The new rule is if the chain ends with `:`, then the block applies to the last
set of prerequisites. Otherwise, it applies to the last set of targets. For
example:
./: exe{test}: cxx{main}
{
test = true # Applies to the exe{test} target.
}
./: exe{test}: libue{test}:
{
bin.whole = false # Applies to the libue{test} prerequisite.
}
This is actually consistent with both non-chain and non-block cases.
Consider:
exe{test}: cxx{main}
{
test = true
}
exe{test}: libue{test}:
{
bin.whole = false
}
exe{test}: libue{test}: bin.whole = false
The only exception we now have in this overall approach of "if the
dependency declaration ends with a colon, then what follows is for a
prerequisite" is for the first semicolon:
exe{test}:
{
test = true
}
exe{test}: test = true
But that's probably intuitive enough since there cannot be a prerequisite
without a target.
|
|
|
|
We are reusing the buildspec syntax for that.
|
|
|
|
|
|
Value subscript is only recognized in evaluation contexts (due to ambiguity
with wildcard patterns; consider: $x[123].txt) and should be unseparated from
the previous token. For example:
x = ($y[1])
x = (($f ? $y : $z)[1])
x = ($identity($y)[$z])
|
|
|
|
Specifically, now config.<tool> (like config.cli) is handled by the import
machinery (it is like a shorter alias for config.import.<tool>.<tool>.exe
that we already had). And the cli module now uses that instead of custom
logic.
This also adds support for uniform tool metadata extraction that is handled by
the import machinery. As a result, a tool that follows the "build2 way" can be
imported with metadata by the buildfile and/or corresponding module without
any tool-specific code or brittleness associated with parsing --version or
similar outputs. See the cli tool/module for details.
Finally, two new flavors of the import directive are now supported: import!
triggers immediate importation skipping any rule-specific logic while import?
is optional import (analogous to using?). Note that optional import is always
immediate. There is also the import-specific metadata attribute which can be
specified for these two import flavors in order to trigger metadata
importation. For example:
import? [metadata] cli = cli%exe{cli}
if ($cli != [null])
info "cli version $($cli:cli.version)"
|
|
|
|
|
|
Note that the testscript parser (which derives from the buildfile parser) is
(still) not reset'able (this functionality is currently not needed so why
complicate things).
|
|
|
|
|
|
|
|
Before:
x = [string null]
After:
x = [string, null]
|
