You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Swift toolchains override system-provided binaries such as lldb and clang, which might not be suitable for non-Swift-related things that people may want to do on the same system. Also, using ~/.local/bin to store the binaries is not ideal since ~/.local/bin is also the place for the user to put their own binaries, so if they want to temporarily go back to the system binaries they can't simply remove ~/.local/bin from the path. Since there's an activation script already, the activation script could be modified to change this to something like ~/.local/share/swiftly/current/bin, so then the user could still have their personal binaries on PATH if they don't source the swiftly activation script. Also, the "use" mechanism might be able to be modified to allow unusing a toolchain.
The text was updated successfully, but these errors were encountered:
The next version of swiftly will be changing a number of these things. The swiftly binaries and symlinks no longer go into ~/.local/bin. Instead, they will go into ~/.local/share/swiftly/bin and you have the option of whether or not to automatically add this to your path with a flag at initialization time.
In terms of unusing a toolchain, there is no way to do that currently. Hopefully the mechanism above is enough to allow you to switch between other paths that provide the clang, lldb, and other overlapping tools.
Swift toolchains override system-provided binaries such as lldb and clang, which might not be suitable for non-Swift-related things that people may want to do on the same system. Also, using ~/.local/bin to store the binaries is not ideal since ~/.local/bin is also the place for the user to put their own binaries, so if they want to temporarily go back to the system binaries they can't simply remove ~/.local/bin from the path. Since there's an activation script already, the activation script could be modified to change this to something like ~/.local/share/swiftly/current/bin, so then the user could still have their personal binaries on PATH if they don't source the swiftly activation script. Also, the "use" mechanism might be able to be modified to allow unusing a toolchain.
The text was updated successfully, but these errors were encountered: