[cfe-dev] Macros for revision number and commit hash

[Reid Kleckner via cfe-dev]

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.

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.

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.

On Mon, Mar 18, 2019 at 9:50 AM James Y Knight via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> This seems mostly harmless -- except that I'd be worried that people will
> actually use them, when they probably shouldn't. :)
>
> 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.
>
> 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?)
>
>
> On Fri, Mar 15, 2019 at 5:13 PM JF Bastien via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Hello macro enthusiasts!
>>
>> By default, clang defines a lot of macros that allow developers to
>> figure out things about the compiler that’s building them. I’m proposing
>> that we add two more:
>>
>>    1. __clang_revision_number__ : an unsigned integer, representing the
>>    current branch’s revision number.
>>    2. __clang_commit_hash__ : a string containing a hexadecimal hash,
>>    representing the current checkout’s hash.
>>
>> 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, captured on the git migration page
>> <https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git>
>> .
>>
>> Here are examples of similar numbers we currently offer:
>>
>> auto major     = __clang_major__;      // 7
>> auto minor     = __clang_minor__;      // 0
>> auto patch     = __clang_patchlevel__; // 0
>> auto version   = __clang_version__;    // "7.0.0 (tags/RELEASE_700/final
>> 342594)”
>> auto VERSION   = __VERSION__;          // "4.2.1 Compatible Clang 7.0.0
>> (tags/RELEASE_700/final 342594)”
>> auto gnu_major = __GNUC__;             // 4
>> auto gnu_minor = __GNUC_MINOR__;       // 2
>> auto gnu_patch = __GNUC_PATCHLEVEL__;  // 1
>> auto gxx_abi   = __GXX_ABI_VERSION;    // 1002
>>
>>
>> The two new values will be generally useful to tools that automatically
>> handle revisions. For example, we currently have bots that parse clang -v,
>> 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.
>>
>> Let us know what you think!
>>
>> JF
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190318/954938a7/attachment.html>