| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Now instead of ignoring imported stuff (which turned out to be racy), we only
consider conditions up to the include boundary. The thinking here is that an
included (but not sourced) buildfile is a standalone entity (e.g., imported
project but also could be just a side-included buildfile).
Note that unfortunately we will still be issuing warnings in imported projects
since there is no straightforward way to know what is being distributed and
what is not while parsing.
|
|
|
|
|
|
|
|
|
|
For example:
import! [metadata, rule_hint=cxx.link] lib = libhello%lib{hello}
|
|
These options can be used to understand which dependency chain causes matching
or execution of a particular target.
|
|
The reset on each modification semantics is used to implement the default
value distinction as currently done in the config module but later probably
will be done for ?= and $origin().
|
|
|
|
|
|
Besides diagnostics, this allows us to use name in the rule hint, for
example:
[rule_name=hello.link] exe{~'/(.*)/'}: obje{~'/\1/'}
{{
$cxx.path -o $path($>) $path($<[0])
}}
[rule_hint=hello] exe{hello}: obje{hello}
obje{hello}: c{hello-c}
|
|
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.
|
|
A project configuration variable with the NULL default value is naturally
assumed nullable, for example:
config [string] config.libhello.fallback_name ?= [null]
Otherwise, to make a project configuration nullable we use the `null`
variable attribute, for example:
config [string, null] config.libhello.fallback_name ?= "World"
|
|
|
|
|
|
|
|
|
|
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.
|
|
We need to do this in order to inject additional pattern prerequisites which
may "pull" additional sources into the distribution.
|
|
|
|
|
|
This variable allows a project to distinguish between development and
consumption builds. While normally there is no distinction between these two
modes, sometimes a project may need to provide additional functionality during
development. For example, a source code generator which uses its own generated
code in its implementation may need to provide a bootstrap step from the
pre-generated code. Normally, such a step is only needed during development.
See "Project Configuration" in the manual for details.
|
|
|
|
In return we get the ability to specify value attributes.
|
|
|
|
|
|
|
|
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.
|
|
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 in addition to the already supported path-based target type/pattern
specific variables. For example:
hxx{*}: x = y # path-based
hxx{~/.*/}: x = y # regex-based
|
|
Use this to relax the pattern inclusion/exclusion syntax to only require
unquoted +/-.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See the config.cxx.translate_include variable documentation in cxx/init.cxx
for details.
|
|
|
|
|
|
depdeb preamble
|
|
|
|
Now triple dot and escape sequence can appear almost anywhere in the target
name (see target::split_name() for details).
|
|
|
|
|
|
This is for consistency with version constraints in manifest.
|
|
|
|
Specifically, they are reserved for future support of arithmetic evaluation
contexts and evaluation pipelines, respectively.
|
