aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/target.hxx
AgeCommit message (Collapse)AuthorFilesLines
2022-04-18Avoid locking target set if in load phaseBoris Kolpackov1-5/+15
2022-04-15Get rid of target::dynamic_type() virtual functionBoris Kolpackov1-35/+85
Instead of overriding this function, derived targets must now set the dynamic_type variable to their static_type in their constructor body.
2022-04-13Cache target base scope lookupsBoris Kolpackov1-5/+31
2022-04-07Rename {match,execute}() to *_sync(), add *_complete()Boris Kolpackov1-2/+2
In particular, the match() rename makes sure it doesn't clash with rule::match() which, after removal of the hint argument in simple_rule, has exactly the same signature, thus making it error-prone to calling recursively.
2022-04-06Add support for rule hintsBoris Kolpackov1-9/+60
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.
2022-03-31Use own type information instead of dynamic_cast in target::is_a()Boris Kolpackov1-6/+29
2022-03-07Add support for update=unmatch|match to ad hoc recipesBoris Kolpackov1-1/+2
2022-03-02Add update operation-specific variable with unmatch|match additional valuesBoris Kolpackov1-12/+19
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.
2022-02-15Diagnose various misuses of library metadata protocolBoris Kolpackov1-1/+1
2022-02-09Don't use fallback file_rule to clean real targetsBoris Kolpackov1-0/+4
2022-02-09Don't skip empty see-through target groupsBoris Kolpackov1-5/+15
2022-01-11Work around VC14 bugBoris Kolpackov1-9/+0
2022-01-10Consider implied targets when resolving dynamic dependenciesBoris Kolpackov1-0/+9
2021-12-16Verify targets that alias same path are read-onlyBoris Kolpackov1-1/+6
2021-12-15Return stable imported target name from import_direct()Boris Kolpackov1-0/+5
2021-09-29Add notion of bundle amalgamation scopeBoris Kolpackov1-0/+6
2021-09-28Adapt to libbutl headers extension change from .mxx to .hxxKaren Arutyunov1-1/+1
2021-09-20Add support for disabling clean through target-prerequisite relationshipBoris Kolpackov1-6/+2
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-3/+6
2021-08-23Clear data in target::data() modifiersBoris Kolpackov1-2/+4
Currently we may end up resetting the data during the rule ambiguity detection.
2021-08-11Optimize process_libraries() some moreBoris Kolpackov1-2/+5
2021-06-08Get rid of special *{} wildcard target type notation in target type/patternsBoris Kolpackov1-1/+1
Explicit target{} should be used instead. Also, in this context, absent target type is now treated as file{} rather than target{}, for consistency with all other cases.
2021-06-08Implement ad hoc regex pattern rule supportBoris Kolpackov1-5/+14
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}
2021-06-08Redo fallback reverse operation machinery in ad hoc recipesBoris Kolpackov1-0/+14
2021-05-28Fix few Windows/VC compatibility issuesBoris Kolpackov1-2/+2
2021-05-28Clean default target type extension logicBoris Kolpackov1-0/+6
2021-05-28Make notion of name pattern explicit, fix various related loose endsBoris Kolpackov1-1/+1
2020-12-15Add explicit owns_lock() call to make Clang 3.7 happyBoris Kolpackov1-1/+1
2020-12-14Fix bug in create_new_target_locked()Karen Arutyunov1-1/+15
2020-12-11Add search_locked() versions of search() functionsBoris Kolpackov1-2/+2
2020-11-17Generalize dot escaping in target name rulesBoris Kolpackov1-3/+4
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-8/+2
2020-09-24Give hints for common causes of "no rule to update ..." errorBoris Kolpackov1-11/+32
2020-08-10Allow holes in group_view arrayBoris Kolpackov1-0/+8
2020-07-17Fix race in path/mtime assignment and file_rule::match()Boris Kolpackov1-0/+13
2020-07-17Add optimized derive_path_with_extension(), use in file_ruleBoris Kolpackov1-0/+17
2020-07-07Skip sources of executables in cc::install_ruleBoris Kolpackov1-5/+5
Failed that, they may pull headers via an ad hoc group.
2020-06-29Add legal{} target type and config.install.legal variableBoris Kolpackov1-1/+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-25Add more instrumentation for unassigned path raceBoris Kolpackov1-0/+12
2020-06-09Make importation of unqualified targets illegalBoris Kolpackov1-0/+4
2020-06-08Hash ad hoc prerequsites for ad hoc recipe change detectionBoris Kolpackov1-0/+5
2020-06-08Adjust rule_match name for ad hoc recipesBoris Kolpackov1-1/+1
2020-06-03Allow process path values and targets as buildscript program namesKaren Arutyunov1-0/+6
Also deduce the recipe name.
2020-06-03Get rid of remaining typedef'sBoris Kolpackov1-1/+1
2020-06-02Add $target.process_path() analogous to $target.path()Boris Kolpackov1-1/+3
2020-05-27Initial support for ad hoc recipes (still work in progress)Boris Kolpackov1-0/+11
2020-04-30Rename target::member to target::adhoc_memberBoris Kolpackov1-5/+5
2020-04-30Factor recipe to separate header/source filesBoris Kolpackov1-46/+2
2020-04-27Get rid of warningsBoris Kolpackov1-20/+3
2020-04-27Rework tool importation along with cli moduleBoris Kolpackov1-3/+60
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)"