Implement project-qualified names/prerequisites, two-stage import

1 files changed, 26 insertions, 1 deletions

diff --git a/build/file b/build/file
index b786cf7..8a5f9fa 100644
--- a/build/file
+++ b/build/file
@@ -11,7 +11,9 @@
 namespace build
 {
   class scope;
+  class target;
   class location;
+  class prerequisite_key;
 
   extern const dir_path build_dir;     // build
   extern const dir_path bootstrap_dir; // build/bootstrap
@@ -92,8 +94,31 @@ namespace build
   void
   load_root_pre (scope& root);
 
+  // Import has two phases: the first is triggered by the import
+  // directive in the buildfile. It will try to find and load the
+  // project. Failed that, it will return the project-qualified
+  // name of the target which will be used to create a project-
+  // qualified prerequisite. This gives the rule that will be
+  // searching this prerequisite a chance to do some target-type
+  // specific search. For example, a C++ link rule can search
+  // for lib{} prerequisites in the C++ compiler default library
+  // search paths (so that we end up with functionality identical
+  // to -lfoo). If, however, the rule didn't do any of that (or
+  // failed to find anything usable), it calls the standard
+  // prerequisite search() function which sees this is a project-
+  // qualified prerequisite and goes straight to the second phase
+  // of import. Here, currently, we simply fail but in the future
+  // this will be the place where we can call custom "last resort"
+  // import hooks. For example, we can hook a package manager that
+  // will say, "Hey, I see you are trying to import foo and I see
+  // there is a package foo available in repository bar. Wanna
+  // download and use it?"
+  //
   list_value
-  import (scope& base, const name&, const location&);
+  import (scope& base, name, const location&);
+
+  target&
+  import (const prerequisite_key&);
 }
 
 #include <build/file.ixx>