aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/file.hxx
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2019-08-16 13:01:56 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2019-08-16 13:01:56 +0200
commit49031af6be4bfb55a8ef64cea08a7161c3a763a4 (patch)
treed88340989291d681b02e04314be84204f3e58f95 /libbuild2/file.hxx
parentde8a68265cd467b7ca225e06501b23a8f38a694e (diff)
Minor cleanups
Diffstat (limited to 'libbuild2/file.hxx')
-rw-r--r--libbuild2/file.hxx35
1 files changed, 16 insertions, 19 deletions
diff --git a/libbuild2/file.hxx b/libbuild2/file.hxx
index e2e8aaa..4d668fe 100644
--- a/libbuild2/file.hxx
+++ b/libbuild2/file.hxx
@@ -203,25 +203,22 @@ namespace build2
LIBBUILD2_SYMEXPORT pair<value, bool>
extract_variable (const path&, const variable&);
- // 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?"
+ // 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, dude, I see you are trying to import
+ // foo and I see there is a package foo available in repository bar. Wanna,
+ // like, download and use it or something?"
//
LIBBUILD2_SYMEXPORT names
import (scope& base, name, const location&);