Age | Commit message (Collapse) | Author | Files | Lines |
|
We still always use the public var_pool from context but where required,
all access now goes through scope::var_pool().
|
|
|
|
|
|
|
|
Specifically, don't try to derive low-verbosity name from what looks like an
eval context of a function call.
|
|
The $find() function returns true if the sequence contains the specified
value. The $find_index() function returns the index of the first element
in the sequence that is equal to the specified value or $size(<sequence>)
if none is found. For string sequences, it's possible to request case-
insensitive comparison with a flag.
|
|
|
|
|
|
|
|
|
|
Having -l options for binless (header-only) libraries makes it unusable from
other build systems. But omitting them could make the metadata incomplete (for
example, importable headers), so we omit that as well.
|
|
|
|
|
|
|
|
|
|
Allowing this seems harmless since all the alias does is pull its
prerequisites. And they are handy to use as metadata carriers.
|
|
|
|
functions
$is_a() returns true if the <name>'s target type is-a <target-type>. Note
that this is a dynamic type check that takes into account target type
inheritance.
$filter[_out]() return names with target types which are-a (filter) or
not are-a (filter_out) one of <target-types>.
In particular, these functions are useful for filtering prerequisite
targets ($<) in ad hoc recipes and rules.
|
|
It returns the list of uint64 integers starting from <begin> (including)
to <end> (excluding) with the specified <step> or 1 if unspecified. For
example:
hdr = foo.hxx bar.hxx baz.hxx
src = foo.cxx bar.cxx baz.cxx
assert ($size($hdr) == $size($src)) "hdr and src expected to be parallel"
for i: $integer_sequence(0, $size($hdr))
{
h = ($hdr[$i])
s = ($src[$i])
...
}
|
|
Specifically, now we can do:
x = [uint64] 0x0000ffff
cxx.poptions += "-DOFFSET=$x" # -DOFFSET=65535
cxx.poptions += "-DOFFSET=$string($x, 16)" # -DOFFSET=0xffff
cxx.poptions += "-DOFFSET=$string($x, 16, 8)" # -DOFFSET=0x0000ffff
Note that there is no hex notation support for the int64 (signed) type.
|
|
This is required, for example, to build QtGui.
|
|
|
|
|
|
|
|
|
|
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).
|
|
overloads
|
|
|
|
|
|
Note that we started with this semantics but it was changed in a commit on
2021-09-16 for reasons not entirely unclear but most likely due to target-
specific variables specified for the group not being set on all the members.
Which we have now addressed (see the previous commit).
Note also that this new (old) semantics is not without its own drawbacks.
Specifically, there is a bit of waste when the target-specific variable is
really only meant for the recipe and thus setting it on all the members is
unnecessary. For example:
<{hxx ixx cxx}{options}>: cli{options}
{
options = ...
}
{{
# Use options.
}}
But this feels like a quality of implementation rather than conceptual
issue. For example, we could likely one day address it by synthesizing a
separate group target for ad hoc groups.
|
|
This is in preparation for (again) not treating primary member of an
ad hoc group as a group for variable lookup.
|
|
|
|
|
|
Specifically, the dist target-specific variable now can specify a path
besides true or false. This path is the "imaginary" source location which
is used to derive the corresponding distribution local. This location can
be either a directory path (to remap with the same file name) or a file
path (to remap with a different name). If the path is relative, then it's
treated relative to the target directory. Note that to make things less
error prone, simple paths without any directory separators are not allowed
(use ./<name> instead).
Note that if multiple targets end up with the same source location, the
behavior is undefined and no diagnostics is issued.
Note also that such remapping has no effect in the bootstrap distribution
mode.
|
|
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.
|
|
|
|
|
|
The original name is still recognized for backwards compatibility.
|
|
|
|
|
|
|
|
|
|
Also, enable this check even if proc_lib is not specified unless in
the execute phase.
|
|
|
|
Specifically, handle the /DEBUG:<value> form in addition to /DEBUG
and recognize /DEBUG:NONE.
|
|
|
|
|
|
|
|
|
|
|