<div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 10, 2012 at 11:31 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@apple.com" target="_blank" class="cremed">echristo@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi guys,<br>
<br>
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.<br>
</blockquote><div><br></div><div>I'm willing to go out on a limb and say its crazy easy already.</div><div><br></div><div>If you want to set CLANG_VENDOR, all you have to do is add a single line to the 'include/clang/Basic/<a href="http://Version.inc.in">Version.inc.in</a>' 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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>I also don't think any of this needs to involve any part of LLVM really...</div><div><br></div><div>-Chandler</div></div></div>