diff options
author | Boris Kolpackov <boris@codesynthesis.com> | 2019-08-16 13:01:56 +0200 |
---|---|---|
committer | Boris Kolpackov <boris@codesynthesis.com> | 2019-08-16 13:01:56 +0200 |
commit | 49031af6be4bfb55a8ef64cea08a7161c3a763a4 (patch) | |
tree | d88340989291d681b02e04314be84204f3e58f95 /libbuild2/file.hxx | |
parent | de8a68265cd467b7ca225e06501b23a8f38a694e (diff) |
Minor cleanups
Diffstat (limited to 'libbuild2/file.hxx')
-rw-r--r-- | libbuild2/file.hxx | 35 |
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&); |