I completely agree with you; having multiple clangs and lldbs and their ancillary libraries is very confusing. It's my understanding, however, that the LLVM org is a separate entity and coordinating the inclusion of Swift would presumably take a fair amount of work.
The fact is that there is no one central LLVM/Clang/Swift toolchain on Linux like there is on macOS, and while it's possible to use containers to isolate these disparate environments, container-based-development workflows aren't as popular as they probably should be.
My suggestion was based on the presumption that the Swift team would continue to move rapidly and thus own the stack; if there's going to be a custom lldb, then don't pretend that it's regular ol' lldb, make it Swift's lldbexplicitly.
I think that this is the misunderstanding. The lldb used for Swift is not a "custom" lldb. It is the llvm.orglldb. The modifications to it are more than what most Linux distributions would do, but, it largely amounts to a single "plugin" (yes, the parlance here is terrible; the plugin concept in LLDB is more heavyweight than what one would traditionally think of as a plugin). This plugin is what is responsible for stitching together the Swift frontend and the LLDB engine.
The complexity of this lies in that you want the same clang and llvm in LLDB as in the Swift compiler and the C/C++ bits - aka, you need the llvm/clang/lldb/swift to all be built at the same point. However, none of the pieces are "custom", excluding, of course, Swift, as that is the language frontend being implemented.
The complexity of this lies in that you want the same clang and llvm in LLDB as in the Swift compiler and the C/C++ bits - aka, you need the llvm/clang/lldb/swift to all be built at the same point.
Yes, you're correct, and another message on the forums here asserts that as well (sorry my searching for it has come up empty so far). An early version of the Fedora Swift package relied on clang from the LLVM project and that lead to issues.
I would be happy to make the Swift package a dependent on the existing LLVM one, but because they are not in sync, troubles emerge quickly. I've also looked into making it an either/or between Swift and LLVM per Fedora's Conflicts policy but have not yet done so.
You cannot use the system provided LLVM because it is still missing changes which could be upstreamed, but have not yet been. There is not a technical issue here, its an issue of working through all the items that need to be completed. Read alternatively: what I am suggesting is replacing the system LLVM/clang with the Swift one.
Yes, I agree completely. Until then, though, it's a bit of a mess (for Fedora packaging, anyway ).
This chain has inspired me to formally ask the Fedora Packaging Committee whether it's possible to have an either/or installation between Swift and regular LLVM; don't know what they'll say but at least the question will be asked.
Are you familiar with the scope of the changes which need to be upstreamed to LLVM/Clang? I guess things related to the Swift calling convention, but is there anything that might be potentially controversial to upstream?
As far as I'm aware, it's not the calling convention, swiftcc is already available upstream, it's a few other things that are maintained in the fork. As of 2016, APINotes and module shadowing were the major fork features, although I wouldn't be surprised if the fork has diverged even more since then.
Question: Should the CentOS 8 toolchain from the download section work for Red Hat 8? If yes, why is this not an "official" statement on the download section? If no, is the Red Hat 8 version at least very close to the CentOS 8 version, so that the existence of the CentOS version facilitates the Red Hat version (and thus more or less ensures that there can be a Red Hat version) or what are the relationships? Since there is an EPEL8 package, I guess it is usable for both CentOS 8 and Red Hat 8, so could this package be listed on the download section (even if "download" might not be the right name for this)?
Is it real pass dependency for build without patching all code ?
I try to build Swift on AltLinux for example, and have a lot troubles with dependencies, because some libs and some includes placed in other place. I override CXXFLAGS LDFLAGS but this is not enough for compile llvm, swift and other libs... I think build fabric (build bot) so complicated for patching or something like that :) For example I know where is placing dependencies but can't easy define it with build script without patch a lot CMakeFile.txt-s ((
).