While working on updates to resolve GCC 16 build issues, I backported an
upstream patch for removing a reference to `<linux/scc.h>` (80fbc4c2a);
simultaneously, a similar patch was added (731832ced) that introduced
the same fix. The conflict wasn't caught during the rebase.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
Updates LLVM_COMPAT to allow building Swift 6 with LLVM/Clang 22, and
reintroduces a `libcxx` USE flag to allow dropping a hard dependency on
GCC <16 on systems that don't want to use it.
Swift 5.10 does not build with Clang 22.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
Backports an upstream patch for building LLVM sanitizers on systems
where `<linux/scc.h>` is no longer present.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
Swift defaults to building against GCC's libstdc++ runtime, but GCC 16's
headers can only be parsed by Clang 22 and later. Swift's LLVM will pick
up on the newest headers available on disk, which means that even if GCC
16 is simply installed on the build machine, Swift will fail to build.
Depending on GCC <16 and explicitly setting `--gcc-install-dir` allows
the right headers to be picked up.
Closes: https://bugs.gentoo.org/974722
Signed-off-by: Itai Ferber <itai@itaiferber.net>
The custom Swift build system doesn't correctly pass
CFLAGS/CXXFLAGS/LDFLAGS to invocations of CMake, nor does the Swift
compiler pick up on those env vars automatically to pass to Clang. The
build system needs to be patched to pass these flags around explicitly,
and a few sites were missed during original patching.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
d201619d3 introduced a check for a Swift compiler to use for
bootstrapping Swift 6, but typo'd the variable name used in one case.
This only affected in-place upgrades with no other Swift version
installed, so wasn't caught in testing.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
When `PYTHON_COMPAT` was updated to support `python3_14`,
`python_gen_cond_dep` wasn't also updated; since we're not trying to
filter Python versions beyond `PYTHON_COMPAT`, we don't actually need to
pass anything in.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
swift-6* ebuilds checked for the latest installed version of
`dev-lang/swift` to build against, but we want to enable bootstrapping
from `dev-lang/swift-bin`. Instead of checking for the latest Swift
using `best_version`, we can check `eselect swift` directly.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
The postrm() phase attempts to remove symlinks to installed Swift
versions; the `rm` invocation was missing `|| die` or `-f` to clearly
indicate what should happen on failure. (In this case, it's okay to
ignore the error and move on.)
Signed-off-by: Itai Ferber <itai@itaiferber.net>
Swift currently fails to build if `dev-libs/libdispatch` is installed
because it globally installs private `libdispatch` headers which get
unexpectedly picked up during the Swift build. Since the headers are not
expected to be present when building Swift on non-Darwin platforms, the
check for the header can be patched out.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
23ea96bd5 added a patch to fix some issues caused by build system
updates; namely, it added some necessary `#include <cstdint>`s that
allowed the project to build. Swift 6.2 requires an additional include
in `FunctionRefInfo.cpp`.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
The build script complains when the same option occurs multiple
times in the same preset, but merges them when they occur in separate
presets. Therefore restore the code that creates a stack of presets
with one for each subsequent argument, instead of packing them all
into a single preset.
Signed-off-by: Katalin Rebhan <me@dblsaiko.net>
Along with `/usr/$(get_libdir)/swift-${PV}`, symlink to a stable
directory in `/usr/$(get_libdir)` that matches the package SLOT so
revdeps can rely on a stable directory that doesn't change on patch
version.
Closes: https://bugs.gentoo.org/957730
Signed-off-by: Itai Ferber <itai@itaiferber.net>
2849e1a7d removed swift-6.0.1, -6.0.1-r1, and -6.0.2, but
swift-5.10.1-r2/backtracing-noexecstack.patch was symlinked to
swift-6.0.1's version. The effective file has been moved down to
swift-5.10.1-r2 and the swift-6.x line now symlinks to this base file;
the contents have not changed.
Closes: https://bugs.gentoo.org/954338
Signed-off-by: Itai Ferber <itai@itaiferber.net>
On `pkg_postinst`, `has_version` wasn't returning the expected value in
order to symlink Swift on first install; instead, we can use `eselect
swift show` itself to be able to tell whether we're eligible to update
the symlinks.
Closes: https://bugs.gentoo.org/951175
Signed-off-by: Itai Ferber <itai@itaiferber.net>
The Swift build system takes a '-j'/'--jobs' flag, but the value from
MAKEOPTS needs to be manually exposed to it for it to be respected.
Closes: https://bugs.gentoo.org/951202
Signed-off-by: Itai Ferber <itai@itaiferber.net>
Swift is now set up to properly respect CFLAGS, CXXFLAGS, and LDFLAGS
from the environment by not overriding those values in the build system.
Swift 6 now also picks up on `SWIFT_EXTRA_BUILD_FLAGS` from the
environment and passes those to its build system as well.
Closes: https://bugs.gentoo.org/939764
Closes: https://bugs.gentoo.org/939766
Signed-off-by: Itai Ferber <itai@itaiferber.net>
Python 3.10 target is scheduled for removal in Gentoo:
https://public-inbox.gentoo.org/gentoo-dev/e6ca9f1f4ababb79ab2a3d005c39b483c3ecef6e.camel@gentoo.org/
Sphinx 8.2.0 already dropped support for CPython 3.10 and PyPy 3.10,
leading to multiple CI failures in ::guru.
We can safely remove this target, because GURU is "experimental" and
does not have stable keywords.
Let's not remove "pypy3" right now because
a) There are not many packages using it.
b) So we can see which packages supported PyPy 3.10, and test them with
PyPy 3.11.
Closes: https://github.com/gentoo/guru/pull/291
Signed-off-by: Anna (cybertailor) Vyalkova <cyber+gentoo@sysrq.in>
Itai Ferber