I wrote a blog post about where I'm currently at with Swift 5.2.1. In short, it works except for the REPL, which I consider essential to the package and don't want to update everyone from 5.1.5 without it.
In a nutshell: my packaging (or contorting ) of Swift to work as an installable package from the Fedora repository seems to hit a snag with 5.2; lldb seems to be unable to start properly without lib files exclusively in /usr/lib, and repl_swift and lldb-server seem to be required to be in /usr/bin instead of where I've been placing them (/usr/libexec/swift-lldb).
I've been considering abandoning the package altogether, and work on getting Python 3 changes integrated so Fedora can have a tarball similar to Ubuntu, but I feel like it would be a regression to stop providing such an easy way to install Swift on a user's machine.
A lot of the content is found relative to executables: that is, a Swift in /foo/bar/bin/swiftc will look for resources in /foo/bar/lib/swift/. I don't know how that applies specifically to the troubles you're seeing with LLDB, but it might be a hint for the Clang headers, at least.
I think this all really depends on what your goals are and what Fedora's policies allow. For example, have you considered just setting the Swift install prefix to /usr/lib/swift and then selectively dropping symlinks into /usr/bin?
That's pretty much what I thought. I get that my situation is outside the scope of Swift Project and is definitely self-inflicted; another avenue I'm looking into is asking the Fedora Council about making the swift-lang package an xor with the Clang/LLVM/LLDB ones. I have tested a version that puts everything into /usr in the same way as the Swift package does it, and it should come as no surprise that it works fine.
I'd wager that making projects that depend on LLVM but aren't a part of LLVM (like Swift) be mutually exclusive with LLVM itself would be rather unpopular.
As an aside, have you looked into Fedora's "alternatives" infrastructure? I'd imagine that Swift's lldb ought to be registered as an alternative to lldb from LLVM proper.
That is often not feasible because lldb and clang released with the Swift toolchains lag quite a bit behind the released versions of llvm.
To give some examples, the Fedora llvm package is at version 10, Arch Linux at version 9. Ubuntu 18.04 is at version 6, but 20.04 will ship with 10 as well. The Swift 5.2 toolchain is based on version 7. The 5.3 nightlies are based on version 10, but those won't ship for a little while.
The long-term goal really should be to remove the need for a patched clang/lldb/llvm, but in the meantime making it easy to stash the llvm binaries included with Swift away in some directory or under some prefixed name would go a long way to making it easy to package Swift for diverse linux distributions.
Beat me to it; yes Fedora is typically very aggressive in staying up-to-date with the latest-n-greatest LLVM toolchain and so by the time Swift 5.3 ships with Clang 10, Fedora may already be on Clang > 10.
I had mentioned it before (sorry can't find the link), but I was advocating for prepending swift- or somesuch to the binaries so that they could live in /usr/bin without clashing. I still think that's a good idea, though I appreciate the complications that would cause.
@Ron_Olson First of all thanks for your efforts around providing Fedora packages for Swift! Are you just repackaging the Ubuntu build, or are you building from source? We landed a few patches on master to allow building on Fedora based system recently, so it would be great if you could try building master and provide feedback. We also opened the development of Swift on Linux 5.2.2 earlier this week and have already backported some of those changes already and are planning to do that for all of them until the release at the end of this month.
I'm building from source (this is a Fedora requirement). Is this one of the patches you referred to? That particular one went a long way to making Swift available on Fedora for me to work on.
I just checked one of my servers that checks out master and builds everything every night and yes! There is a swift.tar.gz and a working Swift toolchain! Looks like you got a lot of the Python code working under 3, and that was the biggest hangup. Thanks a lot for that!
I still have the packaging issues discussed above, but at least it's nice that master is buildable without any additional patching.
That is not one of those patches, but thanks for linking it! Some of the things we observed were failures in core library tests and SPM only supporting Debian based systems. So it should have been possible to build on other systems (given that you had Python 2 installed), but some tests and some core library functionality did not work as expected. Those should all be fixed and are/will be backported to 5.2 with the next Linux dot release.
Thanks @GalenRhodes for the encouragement. In fact, I didn't give up and have a new solution that works a lot better; in a nutshell I moved the entire toolchain to /usr/libexec/swift and symlinked swift and swiftc to /usr/bin and that works great! Both compiling and the REPL works fine.
I've asked the Fedora Packaging Committee if I can reorganize the package to this new structure (and as a consequence created message recursion ). I have test builds of the reorganized structure and I'm hoping that, assuming they say yes, that 5.2.1 will land in Fedora/CentOS/RHEL pretty soon.
Sure, if you have Fedora 31 for x86_64, there's a build available here. I ran test builds for 31, 32, EPEL 8, both ARM and Intel so if you want to try it on your Raspberry Pi running Fedora, I gotcha covered.
One thing to note about this test build: I experimented with removing regular Clang as a dependency; if you want to compile Swift programs, run dnf install clang before doing so. This will not be an issue going forward.
Also, if you have swift-lang installed already, you have to manually uninstall it (dnf remove swift-lang-runtime, which will automatically remove swift-lang) as I haven't worked out the migration code from the old package configuration to this one.
Hey @dinama! You're more than welcome to everything. I have all the patches and files here. Note that if you want the patch to move lldb to /usr/libexec/ then check out the Swift 5.2 branch.
I suggest though, that you try what I'm now doing: I'm putting the entire build tree in /usr/libexec/swift and symlinking swift, swiftc, and sourcekit-lsp to /usr/bin and that has been working great! The REPL, compiling, and the SourceKit stuff for NeoVim has been working great without any patches to re-organize where things look for other things.
) of Swift to work as an installable package from the Fedora repository seems to hit a snag with 5.2; 
). I have test builds of the reorganized structure and I'm hoping that, assuming they say yes, that 5.2.1 will land in Fedora/CentOS/RHEL pretty soon.