<div>That's reasonable I think</div><div><br><div class="gmail_quote"><div>On Fri, Mar 3, 2017 at 12:36 PM Martin Kelly <<a href="mailto:mkelly@xevo.com">mkelly@xevo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 03/03/2017 12:23 PM, Khem Raj wrote:<br class="gmail_msg">
> On Fri, Mar 3, 2017 at 12:15 PM, Martin Kelly <<a href="mailto:mkelly@xevo.com" class="gmail_msg" target="_blank">mkelly@xevo.com</a>> wrote:<br class="gmail_msg">
>> On 03/03/2017 12:12 PM, Khem Raj wrote:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> with meta-clang there is no desire to support multiple versions of<br class="gmail_msg">
>>> llvm and thats why versioning was dropped however, I would still like<br class="gmail_msg">
>>> to fix the versioning if that makes it more useful.<br class="gmail_msg">
>>><br class="gmail_msg">
>><br class="gmail_msg">
>> OK, keeping a single version is certainly simpler. Could you clarify "I<br class="gmail_msg">
>> would still like to fix the versioning if that makes it more useful." ?<br class="gmail_msg">
>><br class="gmail_msg">
><br class="gmail_msg">
> say if there are other apps which depend on the versioning and<br class="gmail_msg">
> otherwise would need patching to work with llvm from meta-clang, then<br class="gmail_msg">
> lets fix it in meta-clang.<br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
From my investigation, it looks like the real (unwrapped) llvm-config<br class="gmail_msg">
is in the PATH for any recipe depending on clang-native. This means that<br class="gmail_msg">
when an app looks for llvm-config, it will find the real version and<br class="gmail_msg">
won't know that the wrapper went anywhere. Of course, if the app truly<br class="gmail_msg">
depends on a specific LLVM version -- due to LLVM's unstable ABI -- then<br class="gmail_msg">
that app will break when the meta-clang version changes. However, if we<br class="gmail_msg">
don't maintain multiple versions of LLVM in meta-clang, that's unavoidable.<br class="gmail_msg">
<br class="gmail_msg">
So AFAICT we could safely remove the wrapper and have apps that set<br class="gmail_msg">
WANT_LLVM_RELEASE still work correctly, if they compile against our<br class="gmail_msg">
version of meta-clang. Since it appears the wrapper has been broken for<br class="gmail_msg">
for some time anyway, I'm guessing there aren't many such apps anyway.<br class="gmail_msg">
<br class="gmail_msg">
Does that sound reasonable to you?<br class="gmail_msg">
</blockquote></div></div>