[libcxx-commits] [libcxx] Simplify the __assertion_handler build logic. Be friendly to IDEs. (PR #93333)

[via libcxx-commits]

EricWF wrote:

> Let's say you configure libc++ with a custom assertion handler. Will your IDE assume that `libcxx/include/__assertion_handler` is being used even though the configuration says otherwise?

Very good point. Since you're open to a more holistic solution, this would be a problem.

> 
> If so, then isn't this the wrong way to fix this issue? Couldn't we instead teach the IDE what we're really doing? What IDE are you using, by the way?

I use CLion, but you can think of the problem very generally. In order for a tool to understand a file, it needs to know how to compile with it. For example, if you can compile a file using `clang++ <whatever-flags-you-want> -I libcxx/include <whatever-other-flags-you-want>`, then you can make tooling work. 

I think the most appropriate solution given our recent discussion is to simply generate the `__assertion_handler` into the target include directory rather than the one containing the header copies.  This would work everywhere except on Apple platforms.

(Which would allow the command line `clang++ -nostdinc++ -I build/include/<target>/c++/v1 -I libcxx/include ...`) 


https://github.com/llvm/llvm-project/pull/93333