aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--libbuild2/module.cxx47
1 files changed, 34 insertions, 13 deletions
diff --git a/libbuild2/module.cxx b/libbuild2/module.cxx
index 02ea64d..ff705eb 100644
--- a/libbuild2/module.cxx
+++ b/libbuild2/module.cxx
@@ -236,7 +236,7 @@ namespace build2
#endif
const string& mod,
const location& loc,
- bool boot,
+ bool /* boot */,
bool opt)
{
tracer trace ("import_module");
@@ -249,19 +249,38 @@ namespace build2
else if (mod == "install") return &install::build2_install_load;
else if (mod == "test") return &test::build2_test_load;
- bool bundled (bundled_module (mod));
-
- // Importing external modules during bootstrap is problematic: we haven't
- // loaded config.build nor entered all the variable overrides so it's not
- // clear what import() can do except confuse matters. So this requires
- // more thinking.
+ // Note that importing external modules during bootstrap is problematic
+ // since we haven't loaded config.build nor entered non-global variable
+ // overrides. We used to just not support external modules that require
+ // bootstrapping but that proved to restrictive. So now we allow such
+ // modules and the following mechanisms can be used to make things work
+ // in various situations:
//
- if (boot && !bundled)
- {
- fail (loc) << "unable to load build system module " << mod <<
- info << "loading external modules during bootstrap is not yet "
- << "supported";
- }
+ // 1. Module is installed.
+ //
+ // This covers both user-installed modules as well as the module's
+ // *-tests in our CI setup (where we install the module next to the
+ // build system).
+ //
+ // 2. Module is specified with global !config.import.<module> override.
+ //
+ // This covers development (where the override can be specified in the
+ // default options file) and could cover imports from the bpkg-managed
+ // host configuration if we use global overrides to connect things
+ // (which feels correct; we shouldn't have multiple host configurations
+ // in any given build).
+ //
+ // One case that is not straightforward is using the module in testscript-
+ // generated tests (e.g., in module's *-tests). This will work in CI
+ // (installed module) and in development provided !config.import.* is
+ // specified in the default options file (and we haven't suppressed it).
+ //
+ // In fact, this is not specific to modules that require bootstrapping; we
+ // have the same config.import.* propagation problem from, say, *-tests's
+ // config.build. To make other cases work (config.import.* specified in
+ // places other than the default options file) we would have to propagate
+ // things explicitly. So for now the thinking is that one shouldn't write
+ // such tests except in controlled cases (e.g., module's *-tests).
module_load_function* r (nullptr);
@@ -281,6 +300,8 @@ namespace build2
#else
context& ctx (bs.ctx);
+ bool bundled (bundled_module (mod));
+
// See if we can import a target for this module.
//
path lib;