| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
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.
|
|
|
|
|
|
To capture literal newline, use quoting.
|
|
Now only unquoted, literal names are recognized as directives, for
example:
'print' = abc
print $print
|
|
Now it is just a stub that prints the function name and its argument.
Currently only single argument can be passed (no value pack support
yet).
|
|
For now it acts as just the value mode that can be enabled anywhere
variable expansion is supported, for example:
(foo=bar):
And the primary use currently is to enable/test quoted and indirect
variable expansion:
"foo bar" = FOO BAR
print $"foo bar" # Invalid.
print $("foo bar") # Yeah, baby.
foo = FOO
FOO = foo
print $($foo)
Not that you should do something like this...
|
|
|
|
Currently, $(foo)-style variable expansion is not supported.
|
|
|
|
Now the src directory is entered into the scope map and points to
the same scope as out. This means that targets that are in src,
not out (e.g., source files) will "see" rules, variables, etc.
This becomes important when we try, for example, to install a
source file (say, a header) from src: we need the rule as well
as the install.* variables.
|
|
|
|
|
|
|
|
|
|
|
|
Specifically, now postponed is only used by the execution mode logic
and rules should not return it directly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Now postponed takes precedence over changed.
|
|
|
|
|
|
|
|
|
|
Currently we only capture their directories without the project
names. We will need project names when we hook import search into
this.
|
|
|
|
|
|
Now the target type and rule maps are in scopes (builtins -- in global
scope). We also now have the map of loaded modules in the root scope of
each project.
|
|
|
|
|
