| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
This functionality is enabled with the depdb-dyndep --dyn-target option. Only
the make format is supported, where the listed targets are added as ad hoc
group members (unless already specified as static members). This functionality
is not available in the --byproduct mode.
|
|
|
|
|
|
|
|
|
|
x [...], for x [...])
|
|
|
|
|
|
reproducers
|
|
|
|
|
|
in script
|
|
We still always use the public var_pool from context but where required,
all access now goes through scope::var_pool().
|
|
Specifically, don't try to derive low-verbosity name from what looks like an
eval context of a function call.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For example, this allows a Qt moc rule not to list generated headers
from libQtCore since they are pre-generated by the library.
|
|
These options can be used to understand which dependency chain causes matching
or execution of a particular target.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Also add a few tests for depdb-dyndep.
|
|
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.
|
|
|
|
|
|
|
|
Specifically, the `depdb dyndep` builtin now has the --byproduct option (which
must come first). In this mode only the --file input is supported. For example:
obje{hello.o}: cxx{hello}
{{
o = $path($>)
t = $(o).t
depdb dyndep --byproduct --what=header --default-type=h --file $t
diag c++ ($<[0])
$cxx.path $cxx.poptions $cc.poptions $cc.coptions $cxx.coptions $cxx.mode -o $o -MD -MF $t -c $path($<[0])
}}
Naturally, this mode does not support dynamic auto-generated prerequisites.
If present, such prerequisites must be specified statically in the buildfile.
Note also that the --default-prereq-type option has been rename to
--default-type.
|
|
Specifically, add the new `depdb dyndep` builtin that can be used to extract
dynamic dependencies from a program run or a file. For example:
obje{hello.o}: cxx{hello}
{{
s = $path($<[0])
depdb dyndep $cxx.poptions $cc.poptions --what=header --default-prereq-type=h -- $cxx.path $cxx.poptions $cc.poptions $cxx.mode -M -MG $s
diag c++ ($<[0])
o = $path($>)
$cxx.path $cxx.poptions $cc.poptions $cc.coptions $cxx.coptions $cxx.mode -o $o -c $s
}}
Currently only the `make` dependency format is supported.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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}
|
|
|
