<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    So here's a concrete proposal...<br>
    <br>
    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...<br>
    <br>
    <b>#ifndef NDEBUG</b><br>
    <br>
    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!<br>
    <br>
    <b>undefs</b><br>
    <br>
    Some examples from llvm/include and clang/include:<br>
    <br>
    <code>#undef NetBSD</code><code><br>
    </code><code>#undef mips</code><code><br>
    </code><code>#undef sparc</code><code><br>
    </code><code>#undef INT64_MAX</code><code><br>
    </code><code>#undef alloca</code><br>
    <br>
    This is not OK to do globally -- even if LLVM doesn't care about the
    definition, maybe embedding applications or OS headers do?<br>
    <br>
    <code>$ find include -iname '*.h' | xargs grep '^#' -- | grep -vE
      '^.*:.*(LLVM_|cplusplus|endif|else|include|define )'| grep -vw
      Support | wc -l</code><code><br>
    </code><code>      </code><code><b>57</b></code><br>
    <br>
    I think it's perfectly realistic to get that number down to 0.<br>
    <br>
    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.<br>
    <br>
    This is something we can start working towards today. Any
    objections?<br>
    <br>
    Alp.<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" href="http://www.nuanti.com">http://www.nuanti.com</a>
the browser experts
</pre>
  </body>
</html>