aboutsummaryrefslogtreecommitdiff
path: root/build/file
diff options
context:
space:
mode:
Diffstat (limited to 'build/file')
-rw-r--r--build/file27
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>