| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
Also fix bug in $string.replace().
|
|
|
|
|
|
For background, see:
https://developercommunity.visualstudio.com/t/Please-clarify-ifwhen-Zc:preprocessor/10537317
|
|
In particular, this option enables C23 typeof support.
|
|
|
|
Note that Clang 17 is not longer supported with regards to standard
library modules.
|
|
|
|
|
|
Specifically:
- Pass -fansi-escape-codes for Clang on Windows.
- Enable diagnostics color by default if already enabled on the terminal.
Only try to enable it ourselves with explicit --diag-color.
|
|
|
|
|
|
|
|
|
|
The semantics is equivalent to the --success option we already have in the
timeout builtin.
|
|
GitHub issue #372.
|
|
GitHub issue #277.
|
|
|
|
|
|
These are parallel to ~host and ~build2 but with suppressed C/C++ compiler
warnings.
Note also that the C++ ad hoc recipes are now by default built in
~build2-no-warnings instead of ~build2 unless the project is configured for
development with config.<project>.develop=true.
|
|
|
|
|
|
|
|
|
|
Specifically, both the C/C++ compiler and link rules now recognize the
cc.serialize boolean variable which instructs them to compiler/link
serially with regards to any other recipe.
This is primarily useful when compiling large translation units or linking
large binaries that require so much memory that doing that in parallel with
other compilation/linking jobs is likely to summon the OOM killer. For
example:
obj{memory-hog}: cc.serialize = true
|
|
In particular, this can be used to make sure no other recipe is being
executed in parallel with the caller.
|
|
Fixes GH issue #361.
|
|
Fixes GH issue #362.
|
|
Fixes GH issue #365.
|
|
Fixes GH issue #368.
|
|
Fixes GH issue #366.
|
|
|
|
|
|
These expose the std::map<json_value,json_value> and std::set<json_value>
types to buildfiles.
New functions:
$size(<json-set>)
$size(<json-map>)
$keys(<json-map>)
Note that the $keys() function returns the list of map key as a json array.
For example:
m = [json_map] 2@([json] a@1 b@2) 1@([json] 1 2)
s = [json_set] ([json] x@1 y@2) ([json] a@1 b@2)
print ($m[2][b]) # 2
print ($s[([json] y@2 x@1)]) # true
|
|
|
|
|
|
This exposes the std::set<std::string> type to buildfiles.
New functions:
$size(<string-set>)
Subscript returns true if the value is present and false otherwise (so
it is mapped to std::set::contains()). For example:
set = [string_set] a b c
if ($set[b])
...
Note that append (+=) and prepend (=+) have the same semantics
(std::set::insert()). For example:
set = [string_set] a b
set += c b # a b c
set =+ d b # a b c d
Example of iteration:
set = [string_set] a b c
for k: $set
...
|
|
This exposes the std::map<std::string,std::string> type to buildfiles.
New functions:
$size(<string-map>)
$keys(<string-map>)
Subscript can be used to lookup a value by key. The result is [null] if
there is no value associated with the specified key. For example:
map = [string_map] a@1 b@2 c@3
b = ($map[b]) # 2
if ($map[z] == [null])
...
Note that append (+=) is overriding (like std::map::insert_or_assign())
while prepend (=+) is not (like std::map::insert()). In a sense, whatever
appears last (from left to right) is kept, which is consistent with what
we expect to happen when specifying the same key repeatedly in a literal
representation. For example:
map = [string_map] a@0 b@2 a@1 # a@1 b@2
map += b@0 c@3 # a@1 b@0 c@3
map =+ b@1 d@4 # a@1 b@0 c@3 d@4
Example of iteration:
map = [string_map] a@1 b@2 c@3
for p: $map
{
k = $first($p)
v = $second($p)
}
While the subscript is mapped to key lookup only, index-based access can be
implemented (with a bit of overhead) using the $keys() function:
map = [string_map] a@1 b@2 c@3
keys = $keys($m)
for i: $integer_sequence(0, $size($keys))
{
k = ($keys[$i])
v = ($map[$k])
}
Also, this commit changes the naming of other template-based value types (not
exposed as buildfile value types) to use C++ template id-like names (e.g.,
map<string,optional<bool>>).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
