| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Note that the unmatch (match but do not update) and match (update during
match) values are only supported by certain rules (and potentially only for
certain prerequisite types).
Additionally:
- All operation-specific variables are now checked for false as an override
for the prerequisite-specific include value. In particular, this can now be
used to disable a prerequisite for update, for example:
./: exe{test}: update = false
- The cc::link_rule now supports the update=match value for headers and ad hoc
prerequisites. In particular, this can be used to make sure all the library
headers are updated before matching any of its (or dependent's) object
files.
|
|
|
|
|
|
This can be achieved with prerequisite-specific install=true, for example:
exe{foo}: exe{bar}: install = true # foo runs bar
|
|
Our current semantics is to clean any prerequisites that are in the same
project (root scope) as the target and it may seem more natural to rather only
clean prerequisites that are in the same base scope. While it's often true for
simple projects, in more complex cases it's not unusual to have common
intermediate build results (object files, utility libraries, etc) reside in
the parent and/or sibling directories. With such arrangements, cleaning only
in base (even from the project root) may leave such intermediate build results
laying around (since there is no reason to list them as prerequisites of any
directory aliases). So we clean in the root scope by default but now any
target-prerequisite relationship can be marked not to trigger a clean with the
clean=false prerequisite-specific value.
|
|
The implemented solution entails shadowing old phase queues so that helpers
don't pick up old phase tasks and boosting the max_threads count so that we
can create more helpers if all the existing ones are stuck in the old phase.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
While we could automatically set it if the target is imported, there is
nothing we can do if the target is used in the same project. So to avoid
confusion we make it mandatory.
|
|
|
|
|
|
|
|
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)"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This would be necessary if someone runs two parallel top-level contexts.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All non-const global state is now in class context and we can now have
multiple independent builds going on at the same time.
|
|
|
|
|
|
libbuild2/algorithm.ixx and referred from libbuild2/target.txx
|
|
|
