| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
See the "Compilation Database" section in the "cc Module" chapter of
the manual for details.
|
|
|
|
Specifically:
1. New --dump-format option. Valid values are `buildfile` and `json-v0.1`.
2. The --dump option now recognizes two additional values: `match-pre` and
`match-post` to dump the state of pre/post-operations. The `match` value
now only triggers dumping of the main operation.
|
|
|
|
Specifically, do not reduce typed RHS empty simple values for prepend/append
and additionally for assignment provided LHS is typed and is a container.
|
|
|
|
Now unqualified variables are project-private and can be typified.
|
|
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.
|
|
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
|
|
|
|
|
|
|
|
We are reusing the buildspec syntax for that.
|
|
|
|
Now a project that disables amalgamation will not logically "see" an outer
project even if it's physically inside its scope.
|
|
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.
|
|
|
|
All non-const global state is now in class context and we can now have
multiple independent builds going on at the same time.
|
|
|
|
|
