From f6319b258bb478e19d4a17852a8406e6b1119b87 Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Sat, 30 Jan 2021 11:06:22 +0200 Subject: Rework include translation support See the config.cxx.translate_include variable documentation in cxx/init.cxx for details. --- libbuild2/cc/utility.hxx | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'libbuild2/cc/utility.hxx') 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&); } } -- cgit v1.1