[OE-core] [meta-clang] clang/LLVM versioning

[Khem Raj]

That's reasonable I think

On Fri, Mar 3, 2017 at 12:36 PM Martin Kelly <mkelly at xevo.com> wrote:

> On 03/03/2017 12:23 PM, Khem Raj wrote:
> > On Fri, Mar 3, 2017 at 12:15 PM, Martin Kelly <mkelly at xevo.com> wrote:
> >> On 03/03/2017 12:12 PM, Khem Raj wrote:
> >>>
> >>> with  meta-clang there is no desire to support multiple versions of
> >>> llvm and thats why versioning was dropped however, I would still like
> >>> to fix the versioning if that makes it more useful.
> >>>
> >>
> >> OK, keeping a single version is certainly simpler. Could you clarify "I
> >> would still like to fix the versioning if that makes it more useful." ?
> >>
> >
> > say if there are other apps which depend on the versioning and
> > otherwise would need patching to work with llvm from meta-clang, then
> > lets fix it in meta-clang.
> >
>
>  From my investigation, it looks like the real (unwrapped) llvm-config
> is in the PATH for any recipe depending on clang-native. This means that
> when an app looks for llvm-config, it will find the real version and
> won't know that the wrapper went anywhere. Of course, if the app truly
> depends on a specific LLVM version -- due to LLVM's unstable ABI -- then
> that app will break when the meta-clang version changes. However, if we
> don't maintain multiple versions of LLVM in meta-clang, that's unavoidable.
>
> So AFAICT we could safely remove the wrapper and have apps that set
> WANT_LLVM_RELEASE still work correctly, if they compile against our
> version of meta-clang. Since it appears the wrapper has been broken for
> for some time anyway, I'm guessing there aren't many such apps anyway.
>
> Does that sound reasonable to you?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170303/81fbfe2f/attachment-0002.html>