aboutsummaryrefslogtreecommitdiff
path: root/libbuild2
AgeCommit message (Collapse)AuthorFilesLines
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>
2024-01-11Fix name recomposition bug in $name.filter*() functionsBoris Kolpackov2-2/+13
2024-01-11Properly split injected ad hoc group member name in regex pattern ruleBoris Kolpackov5-10/+16
2024-01-10Add ability to specify alternative sysroot for pkg-config files (GC issue #59)Boris Kolpackov2-4/+65
Specifically, the new config.cc.pkgconfig.sysroot variable provides roughly equivalent functionality to PKG_CONFIG_SYSROOT_DIR in pkg-config. For details and limitations, see "Rewriting Installed Libraries System Root (sysroot)" in the manual for details.
2024-01-10Fix abs_dir_path conversion diagnosticsBoris Kolpackov1-1/+8
2024-01-10Fix bunch of typosBoris Kolpackov6-10/+10
2024-01-09Disable use of -frewrite-includes for assembler with preprocessor filesBoris Kolpackov1-3/+24
With -frewrite-includes Clang has issues with correctly tracking location information (manifests itself as wrong line numbers in debug info, for example). The result also appears to reference the .Si file instead of the original source file for some reason. While at it also omit trying to scan such files since that can be hazardous (such files sometimes use `#`-style comments).
2024-01-09Allow imported buildfiles to using config.* variables from own projectBoris Kolpackov3-38/+189
2024-01-08Improve documentation commentBoris Kolpackov1-2/+2
2024-01-08Allow specifying compiler mode options in buildfileBoris Kolpackov1-7/+20
Now the configured mode options are appended to buildfile-specified (which must be specified before loading the guess module). In particular, this ability to specify the compiler mode in a buildfile is useful in embedded development where the project may need to hardcode things like -target, -nostdinc, etc. For example: cxx.std = 20 cxx.mode = -target riscv32-unknown-unknown -nostdinc using cxx
2024-01-08Handle absent paths in cc::gcc_header_search_dirs() (e.g., due to -nostdinc)Boris Kolpackov1-8/+17
2024-01-08Add {bin,c,cxx}.types submodules that only register target typesBoris Kolpackov7-166/+371
2023-12-14Allow enabling C++ modules for C++20 and later std.cxx valuesBoris Kolpackov2-90/+243
2023-12-14Cleanup old code for C++ modules support in ClangBoris Kolpackov1-106/+2
2023-12-13Fix another instance of module name not being assigned due to deferred failureBoris Kolpackov1-10/+17
2023-12-12Work around unexecuted member for installed libraries issueBoris Kolpackov4-21/+64
See comment for the long-term plan.
2023-12-11Instrument target::newer() with additional debug informationBoris Kolpackov1-0/+12