aboutsummaryrefslogtreecommitdiff
path: root/libbuild2
AgeCommit message (Collapse)AuthorFilesLines
2024-03-27Filter out config.bin.lib/config.bin.*.lib from ~hostBoris Kolpackov1-10/+22
2024-03-21Improve import diagnosticsBoris Kolpackov1-0/+12
2024-03-19Use new next_word() to observe blank lines for accurate line countBoris Kolpackov1-2/+4
2024-03-01Use original variable name in config reportBoris Kolpackov3-42/+100
2024-02-26Add ability to serialize compilation/linking in cc rulesBoris Kolpackov6-8/+45
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
2024-02-26Add ability to request serialization from schedulerBoris Kolpackov8-31/+128
In particular, this can be used to make sure no other recipe is being executed in parallel with the caller.
2024-02-22Diagnose instead of asserting lib{} group with no membersBoris Kolpackov1-1/+3
Fixes GH issue #361.
2024-02-22Detect dependency cycles in *.export.libsBoris Kolpackov1-0/+5
Fixes GH issue #362.
2024-02-22Diagnose instead of asserting ad hoc group member not already existingBoris Kolpackov1-21/+18
Fixes GH issue #365.
2024-02-22Detect non-cc::link_rule libraries not marked with cc.type=ccBoris Kolpackov2-6/+36
Fixes GH issue #368.
2024-02-22Deal with libs{} being member of group in windows_rpath_timestamp()Boris Kolpackov3-8/+20
Fixes GH issue #366.
2024-02-21Fix issue with json null representation in containersBoris Kolpackov2-2/+13
2024-02-21Improve diagnosticsBoris Kolpackov1-1/+12
2024-02-20Add json_map and json_set buildfile value typesBoris Kolpackov6-95/+197
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
2024-02-20Make json value type prepend non-overriding for consistency with mapBoris Kolpackov3-14/+26
2024-02-20Add custom subscript, iterate functions for vector and set value typesBoris Kolpackov2-5/+83
2024-02-20Add string_set buildfile value typeBoris Kolpackov6-2/+290
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 ...
2024-02-19Add string_map buildfile value typeBoris Kolpackov5-46/+161
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>>).
2024-02-15Add fsdir{} duplicate suppression in more placesBoris Kolpackov4-4/+24
2024-02-14Add comment on json_array assignment issueBoris Kolpackov1-0/+4
2024-02-14Add search_prerequisite*() variants of match_prerequisite*() versionsBoris Kolpackov3-15/+117
2024-02-14Avoid duplicate fsdir{} in inject_fsdir(), match_prerequisite*() call sequencesBoris Kolpackov3-6/+37
2024-02-13Add ability to omit matching in inject_fsdir()Boris Kolpackov4-7/+16
2024-02-13Make target_type non-copyableBoris Kolpackov2-6/+25
2024-02-13Extend json_value C++ interfaceBoris Kolpackov3-18/+240
2024-02-12Add ability to specify recipes in separate filesBoris Kolpackov4-149/+494
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.
2024-02-12Allow overriding apply(match_extra) version in cxx_rule_v1Boris Kolpackov2-5/+29
2024-02-12Extend class target, prerequisite_target interfacesBoris Kolpackov2-6/+38
2024-02-12Extend class prerequisite constructorsBoris Kolpackov3-6/+21
2024-02-12Move to_string(uint64_t,base,width) to utility, use everywhereBoris Kolpackov4-52/+58
2024-02-07Add $json.object_names() functionBoris Kolpackov1-26/+50
2024-02-07Tweak $json.*() function names and semanticsBoris Kolpackov1-11/+37
2024-02-07Use reverse to fundamental types semantics in $json.member_value()Boris Kolpackov2-4/+25
Feels like this is an equivalent context to subscript/iteration.
2024-02-07Map JSON null in subscript/iteration to [null] instead of emptyBoris Kolpackov1-18/+29
This in fact feels more natural in the "for consumption" model and also helps with the nested subscript semantics.
2024-02-07Add support for nested subscript, use for json accessBoris Kolpackov2-92/+105
2024-02-07Add experimental support for JSON value typesBoris Kolpackov9-24/+2831
New types: json json_array json_object New functions: $json.value_type(<json>) $json.value_size(<json>) $json.member_{name,value}(<json-member>) $json.object_names(<json-object>) $json.array_size(<json-array>) $json.array_find(<json-array>, <json>) $json.array_find_index(<json-array>, <json>) $json.load(<path>) $json.parse(<text>) $json.serialize(<json>[, <indentation>]) For example, to load a JSON value from a file: j = $json.load($src_base/board.json) Or to construct it in a buildfile: j = [json] one@1 two@([json] 2 3 4) three@([json] x@1 y@-1) This can also be done incrementally with append/prepend: j = [json_object] j += one@1 j += two@([json] 2 3 4) j += three@([json] x@1 y@-1) Instead of using this JSON-like syntax, one can also specify valid JSON input text: j = [json] '{"one":1, "two":[2, 3, 4], "three":{"x":1, "y":-1}' Besides the above set of functions, other handy ways to access components in a JSON value are iteration and subscript. For example: for m: $j print $member_name($m) $member_value($m) print ($j[three]) A subscript can be nested: print ($j[two][1]) print ($j[three][x]) While a JSON value can be printed directly like any other value, the representation will not be pretty-printed. As a result, for complex JSON values, printing a serialized representation might be a more readable option: info $serialize($j)
2024-02-06Add support for value type-specific subscript and iterationBoris Kolpackov4-110/+205
2024-02-06Fix bunch of maybe used uninitialized warningsBoris Kolpackov6-6/+8
2024-02-02Handle unseparated `rc` and `git` suffixes in Clang version (GH issue #360)Boris Kolpackov1-2/+38
2024-01-29Fix pkgconfig_load() to set common poptions for lib{} target groupKaren Arutyunov1-6/+47
2024-01-23Fix bug in Buildscript pre-parsing logicBoris Kolpackov2-4/+23
2024-01-16Fix bug in import_load() (GH issue #357)Boris Kolpackov1-0/+6
2024-01-16Don't enter exported buildfile as real targets (GH issue #357)Boris Kolpackov1-2/+4
In particular, this used to prevent file_rule from match such targets for clean.
2024-01-16Add add_adhoc_member_identity(), use to fix ad hoc pattern rule logicBoris Kolpackov3-8/+73
2024-01-15Add no_default_target attribute for source, buildfile import directivesBoris Kolpackov2-13/+63
This attribute can be used to disable the default target semantics for the sources/imported buildfile.
2024-01-15Disable default target semantics when loading {bootstrap,root}.buildBoris Kolpackov1-2/+6
2024-01-15Make sure --dump-{scope,target} are specified with --dumpBoris Kolpackov1-0/+12
2024-01-15Automatically alias unknown target types of imported targetsBoris Kolpackov6-47/+140
2024-01-15Fail with unable to import rather than unknown target typeBoris Kolpackov7-25/+140
2024-01-11Add ability to alias target type from another projectBoris Kolpackov3-39/+109
The syntax is: define <type> = <scope>/<type>