| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
The no-newline operators are '<:', '>:', '<<:', and '>>:'.
|
|
|
|
For example:
x = [uint64] 1
x = a # Ok.
|
|
|
|
|
|
So these three are equivalent:
*: foo = 1
{*}: foo = 2
*{*}: foo = 3
|
|
Redesign library importing/exporting while at it.
|
|
|
|
So now we can do:
doc{INSTALL}@./: install = false
Note that so far that's the only place where we support out-qualification.
Grep for @@ OUT to see other places.
|
|
|
|
The 'projects and subprojects' semantics resulted in some counter-intuitive
behavior. For example, in a project with tests/ as a subproject if one builds
one of the tests directly with a non-global override (say C++ compiler), then
the main project would be built without the overrides. I this light,
overriding in the whole amalgamation seems like the right thing to do. The
old behavior can still be obtained with scope qualification, for example:
b ./:foo=bar
|
|
So now we can do:
if true
print true
else
print false
Instead having to do:
if true
{
print true
}
else
{
print false
}
|
|
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
}
|
|
|
|
|
|
|
|
|
|
This is necessary to get rid of bogus restarts in inject_prerequisites()
where it think a group member was updated since its state changed from
unknown to (group's) changed.
|
|
For example:
if ($x == [null])
Or:
if ([uint64] 01 == [uint64] 1)
|
|
|
|
|
|
For example:
print $(dir/:var)
print $(file{target}:var)
print $(dir/file{target}:var)
Note that if the scope/target does not (yet) exists, it will be created.
|
|
For example:
v = [null]
v = [string] abc
v += ABC # abcABC
|
|
Now we can do:
[string] str = foo
|
|
|
|
|
|
|
|
|
|
Before we use to recognize 'x @ y' as a pair. Now it has to be written
unseparated, as 'x@y'. See tests/pairs for details on the new semantics.
|
|
This is part of the "High Fidelity Build" work.
|
|
|
|
|
|
|
|
|
|
The syntax is:
using build@0.1.0-a1
The idea is that we will later also use it for modules and 'build' is
a special, the "build system itself" module.
Also fix a problem with peeking and lexer mode switching.
|
|
Now we can use directive names as variables and targets type, for
example:
print = foo # variable
print{foo}: # target
|
|
if
if!
elif
elif!
else
The expression should evaluate to true of false. The if! and elif!
versions are provided as shortcuts to writing if (!...).
See tests/if-else for examples.
|
|
The syntax is:
using? cli
Now each module use results in two bool variables: <module>.loaded and
<module>.configured.
Also implement variable visibility (the above two variables are limited
to project).
|
|
New syntax:
define cli: file
The rationale is we need to be able to assign the file extension (using
type/pattern-specific variables). And if it is an alias, we will assign
it to the original target type.
Note that we could still support aliases if we need to. Will need to
bring back the id member in target_type that would normally point to
itself but for an alias would point to the origin.
|
|
For example:
define cli=file
Currently, the semantics is that of a real alias with only name differences
that are used for display. See tests/define/buildfile for more use cases.
|
|
For example:
cxx{*-options}: dist = true
1. Only single '*' wildcard is supported, matches 0 or more characters.
2. If target type is not specified, it defaults to any target.
3. Appending (+=) is not allowed.
4. The value is expanded immediately in the context of the scope.
5. The more specific pattern (i.e., with the shortest "stem") is preferred.
If the stem has the same length, then the last defined (but not redefined)
pattern is used. This will probably have to change to become an error.
See tests/variable/type-pattern for more examples.
|
|
See tests/names for more examples.
|
|
Sometimes (e.g., in bpkg configuration) we don't have a project name.
In fact, it is not really a project; it can never be referenced in an
import directive.
So we now have a notion of an unnamed project. Such a project should
still have the 'project' variable set first thing in bootstrap.build
but its value should be empty.
Note that we can still amalgamate such projects just liked named ones.
|
