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

[Ron Lieberman]

Folks,

Thank you for the review comments.

We will follow your suggestion and modify the small number of files locally to achieve our versioning.

 

The patch request is hereby withdrawn.

 

Ron Lieberman

---

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

 

From: cfe-commits-bounces at cs.uiuc.edu [mailto:cfe-commits-bounces at cs.uiuc.edu] On Behalf Of Chandler Carruth
Sent: Tuesday, September 11, 2012 1:49 AM
To: Eric Christopher
Cc: Commit Messages and Patches for LLVM; Sebastian Pop; llvm cfe
Subject: Re: [cfe-commits] revised: [PATCH] Add configuration of CLANG_VENDOR, VENDOR_GCC_VERSION

 

On Mon, Sep 10, 2012 at 11:31 PM, Eric Christopher <echristo at apple.com> wrote:

Hi guys,

I don't think we want to add this functionality into the codebase via configure/cmake. At best I think these should be local files that can be patched by the individual vendors - a small patch to a couple of files is likely to be the least of the work of creating a product. I'm open to ways to make that part of the job easier though.

 

I'm willing to go out on a limb and say its crazy easy already.

 

If you want to set CLANG_VENDOR, all you have to do is add a single line to the 'include/clang/Basic/Version.inc.in' file. It's trivial. That file has never changed since the first time dunbar checked it into the codebase in 2010. It's never going to be a source of merge conflicts or other problems.

 

I actually support a Clang-based toolchain that requires a highly customized version string. To achieve that we had to directly patch lib/Basic/Version.cpp. We changed it to support our custom version strings in 2011, and in all of 2012 we have never had to touch the file to resolve merge conflicts.

 

I think it might be possible to make this even more simple, but I think its reasonable to expect that any further simplifications simplify the normal, existing behavior of upstream Clang in addition to simplifying whatever custom behavior is desired by factoring things differently or generally cleaning up this information.

 

 

I also don't think any of this needs to involve any part of LLVM really...

 

-Chandler

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120911/9f8cbf66/attachment.html>