<div dir="ltr">I don't think NDEBUG is that easy.  We use assert liberally[1] in templated code in headers.  What about cast<>, which has assert(isa<...>...)?  On ELF, you have an ODR problem, and you'll get either one or the other based on the whims of the dynamic linker.<div>
<br></div><div>You could probably get things to the point that it sort of works, but I don't think we could support it without testing.  We could test linking Release clang to Debug LLVM (heck, that probably works, ODR problems aside).</div>
<div><br></div><div>[1] <a href="http://llvm.org/docs/CodingStandards.html#assert-liberally">http://llvm.org/docs/CodingStandards.html#assert-liberally</a></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sun, Nov 10, 2013 at 5:42 AM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  

    
  
  <div 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?<span class="HOEnZb"><font color="#888888"><br>
    <br>
    Alp.<br>
    <br>
    <pre cols="72">-- 
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a>
the browser experts
</pre>
  </font></span></div>

<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>