<div dir="ltr"><div dir="ltr">I don't think the relinking that Chris and Nico brought up is a concern because we already embed the version control info in the binary by default. In other words, we already have this problem, and we already have a variable to disable it for developers: LLVM_APPEND_VC_REV. At least, that's how things are supposed to work.</div><div dir="ltr"><br></div><div>Separately, I don't feel like we should add a pre-defined revision identifier macro to clang just because people find it hard to parse the -v output. Instead, we could resolve to make the formatting more stable, or add some --print-version flag that promises a stable format. Of course, this eventually invites a --print-version2 flag. :) As we're moving to git, the identifier won't be numeric for very long. Surely that will break user assumptions about what our versions look like again, just as changing -v output would.</div><div><br></div><div>We *should* try to bring order to the XCode clang vs. open source clang version numbering, whatever that means. Those are numbers that users might actually want to compare in the pre-processor, so that they don't have to go to these lengths to extract the version or revision from the -v output in the first place.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 18, 2019 at 9:50 AM James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">This seems mostly harmless -- except that I'd be worried that people will actually use them, when they probably shouldn't. :)<div><div><br></div><div>The __clang_revision_number__ value especially, being numeric, seems rather amenable for misuse. Having this as a standalone numeric value, I'd be worried that people would compare against a particular value, without realizing that it's effectively a meaningless number without knowing more about the branch you're talking about (which is rather non-trivial). At least the git hash is more-obviously not usable for ordering. But, exposing that also has some downsides, with lack of flexibility. If it's specified that it must be just a hash, it cannot hold additional info, for example that your build contains uncommitted changes.</div></div><div><br></div><div><div>So, I guess it's not entirely clear to me what useful purpose these values can be used for, for which __clang_version__ isn't already sufficient. (You mention that bots are parsing clang -v -- but to what end?)</div><br class="gmail-m_-8795899037570824307gmail-Apple-interchange-newline"></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2019 at 5:13 PM JF Bastien via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hello <font face="Courier">macro</font> enthusiasts!<div><br></div><div>By default, clang defines a lot of <font face="Courier">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><ol class="gmail-m_-8795899037570824307gmail-m_2580823970329368752MailOutline"><li><font face="Courier">__clang_revision_number__</font> : an unsigned integer, representing the current branch’s revision number.</li><li><font face="Courier">__clang_commit_hash__</font> : a string containing a hexadecimal hash, representing the current checkout’s hash.</li></ol></div><div>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" target="_blank">captured on the git migration page</a>.</div><div><br></div><div>Here are examples of similar numbers we currently offer:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="Courier">auto major = __clang_major__; // 7</font></div><div><font face="Courier">auto minor = __clang_minor__; // 0</font></div><div><font face="Courier">auto patch = __clang_patchlevel__; // 0</font></div><div><font face="Courier">auto version = __clang_version__; // "7.0.0 (tags/RELEASE_700/final 342594)”</font></div><div><font face="Courier">auto VERSION = __VERSION__; // "4.2.1 Compatible Clang 7.0.0 (tags/RELEASE_700/final 342594)”</font></div><div><font face="Courier">auto gnu_major = __GNUC__; // 4</font></div><div><font face="Courier">auto gnu_minor = __GNUC_MINOR__; // 2</font></div><div><font face="Courier">auto gnu_patch = __GNUC_PATCHLEVEL__; // 1</font></div><div><font face="Courier">auto gxx_abi = __GXX_ABI_VERSION; // 1002</font></div></blockquote><div><br>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">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><br></div><div>Let us know what you think!</div><div><br></div><div>JF</div><div><br></div></div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>