<div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 29, 2012 at 3:19 PM, Ron Lieberman <span dir="ltr"><<a href="mailto:ronl@codeaurora.org" target="_blank" class="cremed">ronl@codeaurora.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sebastian and Rafael<br>
<br>
The distinction is subtle, but we are ONLY controlling the GCC version as<br>
output by the -dumpversion flag<br>
The purpose of this configure option is to allow reconfiguration of what is<br>
produced by -dumpversion without having to edit clang sources.<br>
Thus reducing forward maintenance issues for us and others who might choose<br>
to alter this version from its default.<br>
<br>
Default build of clang produces 4.2.1<br>
<br>
clang -dumpversion<br>
4.2.1<br>
<br>
A build configured to produce 6.0.00 for the Hexagon clang product produces<br>
6.0.00<br>
<br>
Hexagon-clang -dumpversion<br>
6.0.00<br>
<br>
The intent of the VENDOR_GCC_VERSION is simply to control what is printed by<br>
the -dumpversion flag.<br>
It does not changenor is it intended to change, the version number of the<br>
product.<br>
<br>
If at some point in the future, someone wishes to implement a configure to<br>
set the product version, they might<br>
Indeed choose to use VENDOR_VERSION.<br>
<br>
So given the above information, I would still suggest keeping it as<br>
VENDOR_GCC_VERSION<br>
<br>
(FYI: a more recent submission has the VERSION in the subject spelled<br>
correctly,  I have altered this one to match)<br></blockquote><div><br></div><div>Ok, I really don't like this.</div><div><br></div><div>There is no GCC version 6.0.00. That doesn't even make sense as a version number.</div>
<div><br></div><div>I think that if you want to deeply change the versions used by clang in this way for a single product you are shipping, you should do so out-of-tree. Having these macros in the tree complicates the code, and makes it more likely that distributions or packagers will (correctly or incorrectly) override them. When that happens, bug reports and issues with upstream Clang become harder to understand and diagnose.</div>
<div><br></div><div>I would be potentially ok with a CLANG_VENDOR string that can be overridden, but only if it is *really* not invasive to the code. Otherwise, I think this should all live out-of-tree.</div></div></div>