[meta-clang] clang/LLVM versioning

[meta-clang] clang/LLVM versioning

[Martin Kelly]

Hi,

I'm attempting to build a recipe using the LLVM/clang cross toolchain 
provided in meta-clang. However, I'm hitting issues with the llvm-config 
wrapper in llvm-common. Specifically, it looks like the wrapper was 
copied over from the LLVM recipe in meta-oe, but the versioning logic 
was not updated, so when the wrapper attempts to exec the versioned 
llvm-config-${WANT_LLVM_RELEASE}, it fails. Notably, LLVM_RELEASE is not 
set in meta-clang/recipes-devtools/clang/clang.inc.

I'm looking into fixing the wrapper, but before I go too far down that 
path, I wanted to get clarification as to the intention of how 
versioning is handled in meta-clang. Specifically, the original LLVM 
recipe was clearly built to support multiple side-by-side LLVM versions 
on the same system. Do we have the same goal for meta-clang? IOW, should 
I make sure that the versioning logic works for meta-clang, or should we 
instead just abandon the versioning (and the wrapper) and support a 
single version of clang/LLVM?

Thanks,
Martin

Re: [meta-clang] clang/LLVM versioning

[Khem Raj]

On Fri, Mar 3, 2017 at 10:44 AM, Martin Kelly <mkelly@xevo.com> wrote:
> Hi,
>
> I'm attempting to build a recipe using the LLVM/clang cross toolchain
> provided in meta-clang. However, I'm hitting issues with the llvm-config
> wrapper in llvm-common. Specifically, it looks like the wrapper was copied
> over from the LLVM recipe in meta-oe, but the versioning logic was not
> updated, so when the wrapper attempts to exec the versioned
> llvm-config-${WANT_LLVM_RELEASE}, it fails. Notably, LLVM_RELEASE is not set
> in meta-clang/recipes-devtools/clang/clang.inc.
>
> I'm looking into fixing the wrapper, but before I go too far down that path,
> I wanted to get clarification as to the intention of how versioning is
> handled in meta-clang. Specifically, the original LLVM recipe was clearly
> built to support multiple side-by-side LLVM versions on the same system. Do
> we have the same goal for meta-clang? IOW, should I make sure that the
> versioning logic works for meta-clang, or should we instead just abandon the
> versioning (and the wrapper) and support a single version of clang/LLVM?
>
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.

> Thanks,
> Martin

Re: [meta-clang] clang/LLVM versioning

[Martin Kelly]

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." ?

I may be missing something, but it seems like the llvm-config wrapper 
script's only job is to point to a versioned installed via 
WANT_LLVM_RELEASE. If that's the case, and if we don't intend to support 
multiple versions, wouldn't it be best simply to remove the wrapper? We 
could fix the wrapper instead, but I think that would have to involve 
reintroducing versioning.

Re: [meta-clang] clang/LLVM versioning

[Khem Raj]

On Fri, Mar 3, 2017 at 12:15 PM, Martin Kelly <mkelly@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.

> I may be missing something, but it seems like the llvm-config wrapper
> script's only job is to point to a versioned installed via
> WANT_LLVM_RELEASE. If that's the case, and if we don't intend to support
> multiple versions, wouldn't it be best simply to remove the wrapper? We
> could fix the wrapper instead, but I think that would have to involve
> reintroducing versioning.

Re: [meta-clang] clang/LLVM versioning

[Martin Kelly]

On 03/03/2017 12:23 PM, Khem Raj wrote:
> On Fri, Mar 3, 2017 at 12:15 PM, Martin Kelly <mkelly@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?

Re: [meta-clang] clang/LLVM versioning

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

That's reasonable I think

On Fri, Mar 3, 2017 at 12:36 PM Martin Kelly <mkelly@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@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?
>

[-- Attachment #2: Type: text/html, Size: 2786 bytes --]