aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/target.cxx
AgeCommit message (Collapse)AuthorFilesLines
2022-03-02Add update operation-specific variable with unmatch|match additional valuesBoris Kolpackov1-13/+60
Note that the unmatch (match but do not update) and match (update during match) values are only supported by certain rules (and potentially only for certain prerequisite types). Additionally: - All operation-specific variables are now checked for false as an override for the prerequisite-specific include value. In particular, this can now be used to disable a prerequisite for update, for example: ./: exe{test}: update = false - The cc::link_rule now supports the update=match value for headers and ad hoc prerequisites. In particular, this can be used to make sure all the library headers are updated before matching any of its (or dependent's) object files.
2021-09-20Add support for disabling clean through target-prerequisite relationshipBoris Kolpackov1-10/+23
Our current semantics is to clean any prerequisites that are in the same project (root scope) as the target and it may seem more natural to rather only clean prerequisites that are in the same base scope. While it's often true for simple projects, in more complex cases it's not unusual to have common intermediate build results (object files, utility libraries, etc) reside in the parent and/or sibling directories. With such arrangements, cleaning only in base (even from the project root) may leave such intermediate build results laying around (since there is no reason to list them as prerequisites of any directory aliases). So we clean in the root scope by default but now any target-prerequisite relationship can be marked not to trigger a clean with the clean=false prerequisite-specific value.
2021-09-15Do variable lookup in ad hoc target groupsBoris Kolpackov1-10/+19
2021-08-11Optimize process_libraries() some moreBoris Kolpackov1-5/+9
2021-05-28Tie loose ends in target type/pattern-specific matchingBoris Kolpackov1-5/+5
2021-05-28Clean default target type extension logicBoris Kolpackov1-15/+21
2021-05-28Make notion of name pattern explicit, fix various related loose endsBoris Kolpackov1-2/+3
2021-04-02Add support for propagating project environmentBoris Kolpackov1-0/+4
2021-03-19Redo entering of src directories into scope_mapBoris Kolpackov1-1/+1
2020-11-17Generalize dot escaping in target name rulesBoris Kolpackov1-45/+271
Now triple dot and escape sequence can appear almost anywhere in the target name (see target::split_name() for details).
2020-09-24Fix target declaration upgrade logicBoris Kolpackov1-4/+8
2020-09-24Give hints for common causes of "no rule to update ..." errorBoris Kolpackov1-13/+9
2020-08-13Fix assertion failure in to_stream() for target key without extensionKaren Arutyunov1-2/+2
Also fix a similar assertion.
2020-07-17Add optimized derive_path_with_extension(), use in file_ruleBoris Kolpackov1-10/+19
2020-07-09Add support for ad hoc importationBoris Kolpackov1-67/+63
2020-06-29Add legal{} target type and config.install.legal variableBoris Kolpackov1-0/+13
This allows separation of legal files (LICENSE, AUTHORS, etc) from other documentation. For example: ./: ... doc{README} legal{LICENSE} $ b install ... config.install.legal=/usr/share/licenses/hello/
2020-06-29Use buildfile{} instead of build{} for target typeBoris Kolpackov1-1/+1
This feels like an oversight from transitioning to full names, like testscript{}, etc.
2020-06-09Handle empty target_key value (directory) in as_name()Boris Kolpackov1-4/+10
2020-06-02Add $target.process_path() analogous to $target.path()Boris Kolpackov1-1/+1
2020-05-27Initial support for ad hoc recipes (still work in progress)Boris Kolpackov1-9/+5
2020-04-30Factor recipe to separate header/source filesBoris Kolpackov1-7/+0
2020-04-27Rework tool importation along with cli moduleBoris Kolpackov1-0/+21
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)"
2020-03-17Rename all find*(variable) to lookup*(variable)Boris Kolpackov1-13/+13
Now we consistently use term "lookup" for variable value lookup. At some point we should also rename type lookup to binding and get rid of all the lookup_type aliases.
2020-02-07Drop copyright notice from source codeKaren Arutyunov1-1/+0
2019-11-18Add couple of sanity checksBoris Kolpackov1-2/+1
2019-11-14Make use of butl::to_stream(ostream, path, bool)Karen Arutyunov1-2/+4
2019-09-04Add support for native shared library versioning on LinuxBoris Kolpackov1-3/+9
Now we can do: lib{foo}: bin.lib.version = linux@1.2 And end up with libfoo.so.1.2 libfoo.so.1 -> libfoo.so.1.2
2019-08-26Implement updating build system modulesBoris Kolpackov1-0/+15
2019-08-23Introduce notion of build contextBoris Kolpackov1-39/+69
All non-const global state is now in class context and we can now have multiple independent builds going on at the same time.
2019-07-01Split build system into library and driverBoris Kolpackov1-0/+1260
generated by cgit v1.1 at 2024-11-05 06:42:06 +0000