| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
Now unqualified variables are project-private and can be typified.
|
|
We still always use the public var_pool from context but where required,
all access now goes through scope::var_pool().
|
|
|
|
|
|
|
|
The problematic scenario this fixes is an ad hoc pattern rule (which
we register for dist in order to inject any additional sources; see
parser.cxx for details) that pulls a tool imported from the system
(say /usr/bin/xxd).
|
|
|
|
This is in preparation for (again) not treating primary member of an
ad hoc group as a group for variable lookup.
|
|
The old semantics was not very consistent, consider:
exe{foo}: cxx{$empty} # Ok.
exe{foo}: cxx{$empty}: include = false # Not ok?
So now both are ok, as well as the block variant:
exe{foo}: cxx{$empty}:
{
include = false
}
Note that the empty prerequisite list in the dependency chain is still an
error:
./: exe{$empty}: cxx{foo} # Error.
Note also that the syntactically-empty prerequisite list was and still is
an error:
exe{foo}: : include = false # Error.
|
|
|
|
|
|
|
|
|
|
|
|
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 +/-.
|
|
|
