[libcxx-commits] [PATCH] D95972: [libc++] Use init_priority(100) when possible

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a comment.

In D95972#3178968 <https://reviews.llvm.org/D95972#3178968>, @mstorsjo wrote:

> CC @thakis
>
> FYI, this change added an inconvenience in builds with clang-cl; the dummy preprocessor line directives (e.g. `# 80 "iostream.cpp" 1 3`) end up output as part of `/showIncludes`, which is what Ninja (and other tools) use for gathering info about the dependencies.
>
> The command output contains this:
>
>   Note: including file:  C:/<builddir>/include/c++/v1\__undef_macros
>   [... more of the same ...]
>   Note: including file: iostream.cpp
>
> The dependency on iostream.cpp is a dummy (the input file isn't found). This causes ninja builds to always rebuild iostream.cpp every time ninja is invoked, even when nothing has been touched. Running with `ninja -d explain` prints:
>
>   ninja explain: output iostream.cpp of phony edge with no inputs doesn't exist
>   ninja explain: iostream.cpp is dirty
>   ninja explain: src/CMakeFiles/cxx_shared.dir/iostream.cpp.obj is dirty
>
> But I'm not sure if this is inconvenience enough to do something about it (I guess alternatives is to either use a windows specific mechanism directly, for setting a high enough priority for the constructors, or to just use the regular priority 101, so it doesn't need the dummy source markers).

FWIW, this workaround has always felt like a hack to me. Now that I think of it, perhaps we can push/pop the system header pragma around it instead?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95972/new/

https://reviews.llvm.org/D95972