[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers

Chris Lattner clattner at apple.com
Sun Nov 10 22:15:10 PST 2013


On Nov 10, 2013, at 5:42 AM, Alp Toker <alp at nuanti.com> wrote:
> 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.

Great!  I strongly agree with your goals, though have a few questions below:

> #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!

+1

> undefs
> 
> Some examples from llvm/include and clang/include:
> 
> #undef INT64_MAX

INT64_MAX is specific to AIX.  I'm not sure that we even build on AIX anymore, but in any case, the people who care about AIX can figure out what they want to do.

> #undef alloca


This looks like a problem in clang/include/Basic/Builtins.h.  I agree it should be fixed.

> #undef NetBSD
> #undef mips
> #undef sparc

These (and the other ones in llvm/Support/Solaris.h) are fine and we should keep them.  These exist because of system headers that trample on the global namespace.  Each of these is also defined with an __ version as well, and are only preserved for legacy reasons.

The only impact of LLVM containing these is that code cannot use the legacy names *and* include an LLVM header.  It seems perfectly reasonable for me to require code to use the __ version of a name if it is updating to use LLVM headers.  Adding new features to legacy code makes that code non-legacy in my books.

-Chris


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


More information about the llvm-dev mailing list