Add support for dynamic dependencies in ad hoc Buildscript recipes

Specifically, add the new `depdb dyndep` builtin that can be used to extract
dynamic dependencies from a program run or a file. For example:

obje{hello.o}: cxx{hello}
{{
  s = $path($<[0])

  depdb dyndep $cxx.poptions $cc.poptions --what=header --default-prereq-type=h -- $cxx.path $cxx.poptions $cc.poptions $cxx.mode -M -MG $s

  diag c++ ($<[0])

  o = $path($>)
  $cxx.path $cxx.poptions $cc.poptions $cc.coptions $cxx.coptions $cxx.mode -o $o -c $s
}}

Currently only the `make` dependency format is supported.

1 files changed, 6 insertions, 23 deletions

diff --git a/libbuild2/cc/utility.hxx b/libbuild2/cc/utility.hxx
index 42e53e3..6ba4a20 100644
--- a/libbuild2/cc/utility.hxx
+++ b/libbuild2/cc/utility.hxx
@@ -9,6 +9,7 @@
 #include <libbuild2/utility.hxx>
 
 #include <libbuild2/target.hxx>
+#include <libbuild2/filesystem.hxx>
 
 #include <libbuild2/bin/target.hxx>
 #include <libbuild2/bin/utility.hxx>
@@ -51,29 +52,11 @@ namespace build2
 
     // Normalize an absolute path to an existing header.
     //
-    // We used to just normalize the path but that could result in an invalid
-    // path (e.g., for some system/compiler headers on CentOS 7 with Clang
-    // 3.4) because of the symlinks (if a directory component is a symlink,
-    // then any following `..` are resolved relative to the target; see
-    // path::normalize() for background).
-    //
-    // Initially, to fix this, we realized (i.e., realpath(3)) it instead.
-    // But that turned out also not to be quite right since now we have all
-    // the symlinks resolved: conceptually it feels correct to keep the
-    // original header names since that's how the user chose to arrange things
-    // and practically this is how the compilers see/report them (e.g., the
-    // GCC module mapper).
-    //
-    // So now we have a pretty elaborate scheme where we try to use the
-    // normalized path if possible and fallback to realized. Normalized paths
-    // will work for situations where `..` does not cross symlink boundaries,
-    // which is the sane case. And for the insane case we only really care
-    // about out-of-project files (i.e., system/compiler headers). In other
-    // words, if you have the insane case inside your project, then you are on
-    // your own.
-    //
-    void
-    normalize_header (path&);
+    inline void
+    normalize_header (path& f)
+    {
+      normalize_external (f, "header");
+    }
   }
 }