[LLVMdev] Goal for 3.5: Library-friendly headers

[Alp Toker]

With the recent thread on using C++11 in LLVM/clang, one of the
recurring themes was a desire to make the internal headers more consumable.

While I don't personally want any kind of stability guarantee for
internal headers, I do think we can do more to ensure that any given
snapshot of the headers is consumable from different compilers and build
configurations.

In practice this means removing certain preprocessor conditionals under
include/ and eventually introducing a config.h in order to make
structures stable across different configurations.

So here's a concrete proposal...

The most common violations I can see at present are in llvm/Support, so
if we skip over it for now (as a candidate for making private), what
remains is actually fairly realistic to clean up...

*#ifndef NDEBUG*

This is the biggest violation. NDEBUG should only ever be used in source
files. That way if something is crashing we can swap in a debug build
without rebuilding every single dependent application. Win!

*undefs*

Some examples from llvm/include and clang/include:

|#undef NetBSD||
||#undef mips||
||#undef sparc||
||#undef INT64_MAX||
||#undef alloca|

This is not OK to do globally -- even if LLVM doesn't care about the
definition, maybe embedding applications or OS headers do?

|$ find include -iname '*.h' | xargs grep '^#' -- | grep -vE
'^.*:.*(LLVM_|cplusplus|endif|else|include|define )'| grep -vw Support |
wc -l||
||      ||*57*|

I think it's perfectly realistic to get that number down to 0.

We can start by putting a check like that in the build system, first to
emit a warning, and ultimately to make violations a build error.

This is something we can start working towards today. Any objections?

Alp.

-- 
http://www.nuanti.com
the browser experts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131110/c19aa42c/attachment.html>