Age | Commit message (Collapse) | Author | Files | Lines |
|
Specifically, now config.<tool> (like config.cli) is handled by the import
machinery (it is like a shorter alias for config.import.<tool>.<tool>.exe
that we already had). And the cli module now uses that instead of custom
logic.
This also adds support for uniform tool metadata extraction that is handled by
the import machinery. As a result, a tool that follows the "build2 way" can be
imported with metadata by the buildfile and/or corresponding module without
any tool-specific code or brittleness associated with parsing --version or
similar outputs. See the cli tool/module for details.
Finally, two new flavors of the import directive are now supported: import!
triggers immediate importation skipping any rule-specific logic while import?
is optional import (analogous to using?). Note that optional import is always
immediate. There is also the import-specific metadata attribute which can be
specified for these two import flavors in order to trigger metadata
importation. For example:
import? [metadata] cli = cli%exe{cli}
if ($cli != [null])
info "cli version $($cli:cli.version)"
|
|
|
|
All non-const global state is now in class context and we can now have
multiple independent builds going on at the same time.
|
|
|
|
|
|
Given test.in containing something along these lines:
foo = $foo$
Now we can do:
using in
file{test}: in{test.in}
file{test}: foo = FOO
The alternative variable substitution symbol can be specified with the
in.symbol variable and lax (instead of the default strict) mode with
in.substitution. For example:
file{test}: in.symbol = '@'
file{test}: in.substitution = lax
|
|
|
|
Instead we now have two more or less separate match states for outer and
inner parts of an action.
|
|
This fixes wrong merging of, say, file{README} and file{README.MySQL}
(in libmysqlclient).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is in preparation for locking its modification/access.
|
|
|
|
|
|
|
|
|
|
|
|
We no longer enter paths from the src tree into scope map. Instead, targets
from the src tree now include their out tree directory (in essence their
"configuration"). This is then used to find a target's scope. See the
comment in class target for details.
The result of this change is that we can now again build multiple
configurations (out trees) for same project at once.
|
|
|
|
|
|
|