| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
These options specify prerequisite targets/patterns to include/exclude (from
the static prerequisite set) for update during match as part of dynamic
dependency extraction (those excluded will be updated during execute). For
example:
depdb dyndep ... --update-exclude libue{hello-meta} ...
depdb dyndep ... --update-exclude libue{*} ...
depdb dyndep ... --update-include $moc --update-include hxx{*} ...
The order in which these options are specified is significant with the first
target/pattern that matches determining the result. If only the
--update-include options are specified, then only the explicitly included
prerequisites will be updated. Otherwise, all prerequisites that are not
explicitly excluded will be updated. If none of these options is specified,
then all the static prerequisites are updated during match. Note also that
these options do not apply to ad hoc prerequisites which are always updated
during match.
|
|
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.
|
|
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}
|
|
|
|
|
|
|
|
This is analogous to what has been done to test and install a couple of
commits before.
|
|
|
|
This is necessary for $target.path() implementation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All non-const global state is now in class context and we can now have
multiple independent builds going on at the same time.
|
|
libbuild2/algorithm.ixx and referred from libbuild2/target.txx
|
|
|
