we have several header files in which the NDEBUG macro is being used. In some of these, the NDEBUG macro changes the size, the interface, or the layout of a type. One example is AssertingVH, which turns into a flat, transparent Value* wrapper in Release build. Now everywhere you use these headers, the state of the NDEBUG flag must be the same, or else bad things could happen.
This turns out to be quite problematic for out-of-tree targets and projects, because it effectively forces them to use the same build type with which LLVM was compiled. Thus, a project maintainer needs to keep a Debug and a Release build of LLVM around, and is mostly barred from using binary distributions.
If the community agrees that this is a problem, I’d like to discuss two possible solutions.
Don’t use NDEBUG (or any similar or depending macro) inside public-facing header files. I think this is the cleanest solution, but it requires a great amount of discipline on the side of developers and reviewers to stick with this pattern, and it will probably have a performance impact (e.g., for AssertingVH).
Replace NDEBUG with a custom flag (e.g. LLVM_NDEBUG), and have CMake take care of synchronizing the two. I.e. ensure that LLVM_NDEBUG is set iff NDEBUG is set. Introducing this is probably a lot more work, because it touches all subprojects.
What do you think?