Sumanth Gundapaneni via llvm-dev
2016-Jul-20 19:47 UTC
[llvm-dev] [CMake] LLVM_PROGRAM_PREFIX support
Hi, I am planning to add support to CMake so that the binaries of llvm will have a prefix appended to it. At this point, I am stuck on which approach to follow 1. Append the prefix during build and install time. If so, this might involve tweaking lit infrastructure to make sure lit picks the prefixed binaries. 2. Append the prefix only during install time. a. Either create symbolic links with prefixed names to existing binaries. On windows this might create copies bloating the install directory b. Or rename the existing binaries with prefixed name. We may not need all the binaries to be prefixed . It doesn't make sense to prefix the utils FileCheck, not, count, llvm-config etc. I might add two CMake variables>LLVM_PROGRAM_PREFIX>LLVM_PROGRAM_PREFIX_EXCLUSION_LIST (This will specify the list of binariesthat don't need a prefix) Let me know your thoughts --Sumanth G -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160720/844e775a/attachment.html>
Martin J. O'Riordan via llvm-dev
2016-Jul-20 19:52 UTC
[llvm-dev] [CMake] LLVM_PROGRAM_PREFIX support
I'm not against the idea, but why do we need prefixes at all? I understand with GCC the need to prefix with the target triple as it uses separate programs for each target, but I think that is not the case with LLVM/CLang. In any case, if prefixes are supported, why not universally apply to all rather than having special exemptions that are going to make generalised build configuration more difficult? MartinO From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Sumanth Gundapaneni via llvm-dev Sent: 20 July 2016 20:48 To: llvm-dev at lists.llvm.org Subject: [llvm-dev] [CMake] LLVM_PROGRAM_PREFIX support Hi, I am planning to add support to CMake so that the binaries of llvm will have a prefix appended to it. At this point, I am stuck on which approach to follow 1. Append the prefix during build and install time. If so, this might involve tweaking lit infrastructure to make sure lit picks the prefixed binaries. 2. Append the prefix only during install time. a. Either create symbolic links with prefixed names to existing binaries. On windows this might create copies bloating the install directory b. Or rename the existing binaries with prefixed name. We may not need all the binaries to be prefixed . It doesn't make sense to prefix the utils FileCheck, not, count, llvm-config etc. I might add two CMake variables>LLVM_PROGRAM_PREFIX>LLVM_PROGRAM_PREFIX_EXCLUSION_LIST (This will specify the list of binariesthat don't need a prefix) Let me know your thoughts --Sumanth G -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160720/dbe6a138/attachment.html>
Krzysztof Parzyszek via llvm-dev
2016-Jul-20 20:30 UTC
[llvm-dev] [CMake] LLVM_PROGRAM_PREFIX support
On 7/20/2016 2:52 PM, Martin J. O'Riordan via llvm-dev wrote:> I’m not against the idea, but why do we need prefixes at all? I > understand with GCC the need to prefix with the target triple as it uses > separate programs for each target, but I think that is not the case with > LLVM/CLangThis has been discussed in the past and there was some interest in this feature. Our use case is that we ship the Hexagon compiler that only has the Hexagon target in it. On top of that, it is a cross-compiler, so it runs on X86, but generates code for Hexagon. All relevant binaries in that installation are prefixed with hexagon-, so that clang is hexagon-clang, etc. This avoids any potential name conflicts with the host clang. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Sumanth Gundapaneni via llvm-dev
2016-Jul-20 20:39 UTC
[llvm-dev] [CMake] LLVM_PROGRAM_PREFIX support
> In any case, if prefixes are supported, why not universally apply to allrather than having special exemptions that are going to make generalised build configuration more difficult? Agree. But, this is purely implementation specific. From: Martin J. O'Riordan [mailto:martin.oriordan at movidius.com] Sent: Wednesday, July 20, 2016 2:53 PM To: 'Sumanth Gundapaneni' <sgundapa at codeaurora.org> Cc: 'LLVM Developers' <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] [CMake] LLVM_PROGRAM_PREFIX support I'm not against the idea, but why do we need prefixes at all? I understand with GCC the need to prefix with the target triple as it uses separate programs for each target, but I think that is not the case with LLVM/CLang. In any case, if prefixes are supported, why not universally apply to all rather than having special exemptions that are going to make generalised build configuration more difficult? MartinO From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Sumanth Gundapaneni via llvm-dev Sent: 20 July 2016 20:48 To: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> Subject: [llvm-dev] [CMake] LLVM_PROGRAM_PREFIX support Hi, I am planning to add support to CMake so that the binaries of llvm will have a prefix appended to it. At this point, I am stuck on which approach to follow 1. Append the prefix during build and install time. If so, this might involve tweaking lit infrastructure to make sure lit picks the prefixed binaries. 2. Append the prefix only during install time. a. Either create symbolic links with prefixed names to existing binaries. On windows this might create copies bloating the install directory b. Or rename the existing binaries with prefixed name. We may not need all the binaries to be prefixed . It doesn't make sense to prefix the utils FileCheck, not, count, llvm-config etc. I might add two CMake variables>LLVM_PROGRAM_PREFIX>LLVM_PROGRAM_PREFIX_EXCLUSION_LIST (This will specify the list of binariesthat don't need a prefix) Let me know your thoughts --Sumanth G -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160720/e4d19154/attachment-0001.html>