Age | Commit message (Collapse) | Author | Files | Lines |
|
$process.run(<prog>[ <args>...])
Return trimmed stdout.
$process.run_regex(<prog>[ <args>...], <pat> [, <fmt>])
Return stdout lines matched and optionally processed with regex.
Each line of stdout (including the customary trailing blank) is matched (as a
whole) against <pat> and, if successful, returned, optionally processed with
<fmt>, as an element of a list.
|
|
|
|
Instead we now have two more or less separate match states for outer and
inner parts of an action.
|
|
|
|
This meta operation can be used to print basic information (name, version,
source/output roots, etc) for one or more projects.
|
|
|
|
|
|
|
|
|
|
|
|
The original semantics turned out to be too restrictive. For example, the
user may have specified the config.c variable on the command line that is
only used by an imported project that is loaded in a subsequent generation.
We are also relaxing it for values since conceptually the two feel the same.
For a value the (hypothetical) example is a "common" variable set in a project
root that is only queried in a subdirectory in a subsequent generation.
|
|
The semantics is similar to the C++11 range-based for:
list = 1 2 3
for i: $list
print $i
Note that there is no scoping of any kind for the loop variable ('i' in
the above example).
See tests/loop/for.test for some examples/ideas.
In the future the plan is to also support more general while-loop as well
as break and continue.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It is still not clear whether this is the right thing to allow, conceptually,
but with this disallowed it's hard to test this functionality. Perhaps we
should have an attribute [overridable]. The problem is one will also have to
set this variable to some value (e.g., [null]) which is not exactly the same
as undefined (especially when testing).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Currently, we only propagate types of sole, unquoted expansions (variable,
function call, or eval context), similar to NULL. To untypify the value,
simply quote it.
|
|
Note that multi-argument functions are not yet "callable" since there is
no support for value packs.
|
|
|
|
|
|
This way we get:
config.import.foo =
Rather than:
config.import.foo = {}
|
|
The empty value is used as a special indicator
|
|
|
|
This solves the problem of changing path spelling on platforms with case-
insensitive filesystems.
For example, you may build a project in the current working directory without
specifying any paths. This means the current working directory will be used as
the project's root. On Windows this could be C:\x.
Now you are building another project that imports the above project and you
specify config.import.x variable pointing to the above build. But you are lazy
to type capital C so you spell it as config.import.x=c:\x.
What happens now is the value from config.import.x is used as the project
root. And now it is a different spelling compared to your original build. This
is not a problem when the build system itself is concerned -- it is smart
enough to use case-insensitive comparison. However, we often use roots to
derive other things, say, -I options that we pass to compilers. And these
options are normally no longer treated as (case-insensitive) paths. If they
are hashed and the result stored in depdb, then we end up with rebuilds that
are triggered by changes from C:\ to c:\.
|
|
|
|
The current model fell apart when we modified values directly.
|
|
Now can write:
if ($build.version > 30000)
|
|
Semantically, these are similar to variable overrides and are essentially
treated as "templates" that are applied on lookup to the "stem" value that is
specific to the target type/name. For example:
x = [string] a
file{f*}: x =+ b
sub/:
{
file{*}: x += c
print $(file{foo}:x) # abc
print $(file{bar}:x) # ac
}
|
|
|
|
value_traits<T>::value_type initialization is not constexpr in VC because
of pointers to function template instantiations (which apparently are not
constexpr).
|
|
Normally the user doesn't need to specify config.bin.target explicitly
since the cxx module will hint it. We now also have the whole set of
target's components:
bin.target.{cpu,vendor,system,version,class}
|
|
For example:
if ($x == [null])
Or:
if ([uint64] 01 == [uint64] 1)
|
|
|
|
Currently, only abs_dir_path inherits from dir_path.
|
|
|
|
|