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

[James Y Knight via cfe-dev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190318/830ff34b/attachment.html>