[cfe-commits] [PATCH] Add configuration of CLANG_VENDOR, VENDOR_GCC_VERSION

[Chandler Carruth]

On Wed, Aug 29, 2012 at 3:19 PM, Ron Lieberman <ronl at codeaurora.org> wrote:

> Sebastian and Rafael
>
> The distinction is subtle, but we are ONLY controlling the GCC version as
> output by the -dumpversion flag
> The purpose of this configure option is to allow reconfiguration of what is
> produced by -dumpversion without having to edit clang sources.
> Thus reducing forward maintenance issues for us and others who might choose
> to alter this version from its default.
>
> Default build of clang produces 4.2.1
>
> clang -dumpversion
> 4.2.1
>
> A build configured to produce 6.0.00 for the Hexagon clang product produces
> 6.0.00
>
> Hexagon-clang -dumpversion
> 6.0.00
>
> The intent of the VENDOR_GCC_VERSION is simply to control what is printed
> by
> the -dumpversion flag.
> It does not changenor is it intended to change, the version number of the
> product.
>
> If at some point in the future, someone wishes to implement a configure to
> set the product version, they might
> Indeed choose to use VENDOR_VERSION.
>
> So given the above information, I would still suggest keeping it as
> VENDOR_GCC_VERSION
>
> (FYI: a more recent submission has the VERSION in the subject spelled
> correctly,  I have altered this one to match)
>

Ok, I really don't like this.

There is no GCC version 6.0.00. That doesn't even make sense as a version
number.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120829/63a97159/attachment.html>