diff options
Diffstat (limited to 'libbuild2/cc/utility.hxx')
-rw-r--r-- | libbuild2/cc/utility.hxx | 26 |
1 files changed, 26 insertions, 0 deletions
diff --git a/libbuild2/cc/utility.hxx b/libbuild2/cc/utility.hxx index a856fd0..42e53e3 100644 --- a/libbuild2/cc/utility.hxx +++ b/libbuild2/cc/utility.hxx @@ -48,6 +48,32 @@ namespace build2 compile_target_types compile_types (otype); + + // 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&); } } |