In the interest of expanding the reach of Swift, I’ve been working on creating an self-contained RPM package for Fedora/Red Hat/CentOS, etc., flavors of Linux. I have a working package that I have submitted for review in a pre-release state, given that it only build successfully using current 4.1-development snapshots. The intention is to have this available once the next version of Swift is officially released, then I’m planning on doing the same thing for Debian/Ubuntu, etc.
There’s a conflict, however, with LLDB, in that there’s the Swift one, and there’s the LLVM-project one. The LLVM toolchain is already available as an installable package and because the lldb executable has the same name in both, there’s an unresolvable conflict between the llvm package and the Swift one.
The only ‘easy’ option I can come up with is to prepend swift-* to the Swift-specific lldb executables. I fully understand that those in the know are shaking their heads and going ‘heh, not that easy pal…’ and while I’m willing to tackle the challenge, I was wondering if this was a worthwhile effort; there would have to be an indicator passed to tell Swift and LLDB that it’s being compiled for Linux packaging and use a different name. This gives rise to the possible precedent of having lldb be named in a different way on Linux than on the Mac, but offers the opportunity to not have conflicts with existing llvm/lldb installations.
So I guess the question is whether this is something that the Swift-LLDB dev team would be okay with, in which case I’d be happy to submit pull requests; if there are reasons why this is not a good idea, then I guess the existing tarball-based installation will suffice.