<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 15, 2019, at 2:13 PM, JF Bastien via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hello <font face="Courier" class="">macro</font> enthusiasts!<div class=""><br class=""></div><div class="">By default, clang defines a lot of <font face="Courier" class="">macros</font> that allow developers to figure out things about the compiler that’s building them. I’m proposing that we add two more:</div><div class=""><ol class="MailOutline"><li class=""><font face="Courier" class="">__clang_revision_number__</font> : an unsigned integer, representing the current branch’s revision number.</li><li class=""><font face="Courier" class="">__clang_commit_hash__</font> : a string containing a hexadecimal hash, representing the current checkout’s hash.</li></ol></div><div class="">These would be set by cmake when building LLVM, and make the most sense in a monorepo on git. There’s been discussion of clang revision number in the context of git migration, <a href="https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git" class="">captured on the git migration page</a>.</div></div></div></blockquote><div><br class=""></div><div>I’m generally +1 on exposing such metadata. The only downside I see is that a git pull could cause a relink of the entire world (even if otherwise unnecessary) just to update these fields. I suspect that this is going to be more painful in a monorepo world for people who work downstream of clang (e.g. LLDB developers).</div><div><br class=""></div><div>Is there an implementation approach that allows us to get the benefit of this extra metadata without reducing dev productivity?</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Here are examples of similar numbers we currently offer:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Courier" class="">auto major = __clang_major__; // 7</font></div><div class=""><font face="Courier" class="">auto minor = __clang_minor__; // 0</font></div><div class=""><font face="Courier" class="">auto patch = __clang_patchlevel__; // 0</font></div><div class=""><font face="Courier" class="">auto version = __clang_version__; // "7.0.0 (tags/RELEASE_700/final 342594)”</font></div><div class=""><font face="Courier" class="">auto VERSION = __VERSION__; // "4.2.1 Compatible Clang 7.0.0 (tags/RELEASE_700/final 342594)”</font></div><div class=""><font face="Courier" class="">auto gnu_major = __GNUC__; // 4</font></div><div class=""><font face="Courier" class="">auto gnu_minor = __GNUC_MINOR__; // 2</font></div><div class=""><font face="Courier" class="">auto gnu_patch = __GNUC_PATCHLEVEL__; // 1</font></div><div class=""><font face="Courier" class="">auto gxx_abi = __GXX_ABI_VERSION; // 1002</font></div></blockquote><div class=""><br class="">The two new values will be generally useful to tools that automatically handle revisions. For example, we currently have bots that parse <font face="Courier" class="">clang -v</font>, and that output is unfortunately aimed at humans (bots aren’t human). That’s broken in the past, and having these two values would help reduce the likelihood of breakage because macros have a pretty stable format and are easy to test.</div><div class=""><br class=""></div><div class="">Let us know what you think!</div><div class=""><br class=""></div><div class="">JF</div><div class=""><br class=""></div></div>_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></body></html>