| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Available overloads:
$sort(<names> [, <flags>])
$sort(<ints> [, <flags>])
$sort(<strings> [, <flags>])
$sort(<paths> [, <flags>])
$sort(<dir_paths> [, <flags>])
The following flag is supported by the all overloads:
dedup - in addition to sorting also remove duplicates
Additionally, the strings overload also support the following flag:
icase - sort ignoring case
Note that on case-insensitive filesystem the paths and dir_paths overload's
order is case-insensitive.
|
|
|
|
|
|
|
|
It is also now possible to adjust this behavior with global
config.install.scope override. Valid values for this variable
are:
project -- only from project
strong -- from strong amalgamation
weak -- from weak amalgamation
global -- from all projects (default)
|
|
|
|
|
|
|
|
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
|
|
Also improve conversion diagnostic.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
than in scope's constructor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Now triple dot and escape sequence can appear almost anywhere in the target
name (see target::split_name() for details).
|
|
|
|
|
|
|
|
Also make sure diff refers program stdout as 'stdout' rather than '-' in the
test rule diagnostics.
|
|
|
|
It turns out that when propagating {c,cxx}.config in tests we don't want to
propagate any options (such as *.std) that have been folded into our project's
mode.
|
|
Before the block used to apply to the set of prerequisites before the last
`:`. This turned out to be counterintuitive and not very useful since
prerequisite-specific variables are a lot less common than target specific.
And it doesn't fit with ad hoc recipes.
The new rule is if the chain ends with `:`, then the block applies to the last
set of prerequisites. Otherwise, it applies to the last set of targets. For
example:
./: exe{test}: cxx{main}
{
test = true # Applies to the exe{test} target.
}
./: exe{test}: libue{test}:
{
bin.whole = false # Applies to the libue{test} prerequisite.
}
This is actually consistent with both non-chain and non-block cases.
Consider:
exe{test}: cxx{main}
{
test = true
}
exe{test}: libue{test}:
{
bin.whole = false
}
exe{test}: libue{test}: bin.whole = false
The only exception we now have in this overall approach of "if the
dependency declaration ends with a colon, then what follows is for a
prerequisite" is for the first semicolon:
exe{test}:
{
test = true
}
exe{test}: test = true
But that's probably intuitive enough since there cannot be a prerequisite
without a target.
|
|
|
|
|
|
Also disable C++ recipe tests when cross-testing.
|
|
Use this information to omit ad hoc C++ recipe tests is testing statically-
linked build system.
|
|
|
|
|
|
|
|
|
