diff options
| author | Boris Kolpackov <boris@codesynthesis.com> | 2020-04-27 09:49:45 +0200 |
|---|---|---|
| committer | Boris Kolpackov <boris@codesynthesis.com> | 2020-04-27 10:03:50 +0200 |
| commit | 9e5750ae2e3f837f80860aaab6b01e4d556213ed (patch) | |
| tree | d3b2e551e444c47b6ce0289969e78360161b6685 /libbuild2/cc/utility.hxx | |
| parent | 028e10ba787a7dbb46e3fcba6f88f496b76cebc5 (diff) | |
Rework tool importation along with cli module
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)"
Diffstat (limited to 'libbuild2/cc/utility.hxx')
| -rw-r--r-- | libbuild2/cc/utility.hxx | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/libbuild2/cc/utility.hxx b/libbuild2/cc/utility.hxx index fa9f165..017765b 100644 --- a/libbuild2/cc/utility.hxx +++ b/libbuild2/cc/utility.hxx @@ -41,10 +41,10 @@ namespace build2 // // The reason we pass scope and not the target is because this function is // called not only for exe/lib but also for obj as part of the library - // meta-information protocol implementation. Normally the bin.*.lib values - // will be project-wide. With this scheme they can be customized on the - // per-directory basis but not per-target which means all exe/lib in the - // same directory have to have the same link order. + // metadata protocol implementation. Normally the bin.*.lib values will be + // project-wide. With this scheme they can be customized on the per- + // directory basis but not per-target which means all exe/lib in the same + // directory have to have the same link order. // lorder link_order (const scope& base, otype); |