That's reasonable I think On Fri, Mar 3, 2017 at 12:36 PM Martin Kelly <[email protected]> wrote:
> On 03/03/2017 12:23 PM, Khem Raj wrote: > > On Fri, Mar 3, 2017 at 12:15 PM, Martin Kelly <[email protected]> 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? >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
