From 37b5871bc8e544885c8a583ac7d242d14e8407c6 Mon Sep 17 00:00:00 2001
From: Boris Kolpackov <boris@codesynthesis.com>
Date: Tue, 8 Sep 2020 07:56:56 +0200
Subject: Allow external modules that require bootstrap

---
 libbuild2/module.cxx | 47 ++++++++++++++++++++++++++++++++++-------------
 1 file 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;
-- 
cgit v1.1