aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/config
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2020-04-27 09:49:45 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2020-04-27 10:03:50 +0200
commit9e5750ae2e3f837f80860aaab6b01e4d556213ed (patch)
treed3b2e551e444c47b6ce0289969e78360161b6685 /libbuild2/config
parent028e10ba787a7dbb46e3fcba6f88f496b76cebc5 (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/config')
-rw-r--r--libbuild2/config/utility.hxx14
1 files changed, 14 insertions, 0 deletions
diff --git a/libbuild2/config/utility.hxx b/libbuild2/config/utility.hxx
index 614791f..fb3023b 100644
--- a/libbuild2/config/utility.hxx
+++ b/libbuild2/config/utility.hxx
@@ -311,6 +311,20 @@ namespace build2
// be used to "remember" that the module is left unconfigured in order to
// avoid re-running the tests, etc.
//
+ // @@ This functionality is WIP/unused and still has a number of issues:
+ //
+ // - This seems to be a subset of a bigger problem of caching discovered
+ // configuration results. In fact, what we do in the configured case,
+ // for example in the cc module (multiple path extraction runs, etc), is
+ // a lot more expensive.
+ //
+ // - The current semantics does not work well for the case where, say, the
+ // missing tool has appeared in PATH and can now be used via the default
+ // configuration. In fact, even reconfiguring will not help without a
+ // "nudge" (e.g., config.<tool>=<tool>). So maybe this value should be
+ // ignored during configuration? See the "Tool importation: unconfigured
+ // state" page for more notes.
+ //
LIBBUILD2_SYMEXPORT bool
unconfigured (scope& rs, const string& var);