aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/target.hxx
AgeCommit message (Collapse)AuthorFilesLines
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)"
2020-03-20Add ability to query whether target has been matched for actionBoris Kolpackov1-3/+9
2020-03-17Rename all find*(variable) to lookup*(variable)Boris Kolpackov1-22/+26
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-10-29Add forward declaration header for build state typesBoris Kolpackov1-3/+1
2019-10-02Allow iterating over group prerequisites during executeBoris Kolpackov1-0/+3
2019-09-04Add support for native shared library versioning on LinuxBoris Kolpackov1-3/+7
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/+4
2019-08-23Introduce notion of build contextBoris Kolpackov1-28/+65
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-08-21Cleanup context.hxx and its usageBoris Kolpackov1-5/+1
2019-08-01Fix linkage failure due to inline functions defined in ↵Karen Arutyunov1-5/+8
libbuild2/algorithm.ixx and referred from libbuild2/target.txx