commit 421db3a07419b389777df12c5ad12cf0c429c822
Author: lucascouts <lucascs@protonmail.com>
Date: Tue Sep 8 13:03:24 2026 -0300

add(media-libs/{draco-1.5.7,meshoptimizer-1.2}), fix(media-gfx/blender-5.2.1-r1): the 5.2 series devendored three libraries, not one

blender-5.2.1-r1 could not be built by anyone, on any arch, for three
independent reasons. Only the first was visible in a bug report; the other two
sit behind it and surface one at a time.

They share a root cause. The 5.2 series systematically removes the vendored
copies under extern/, leaving only the glue in intern/<lib>_bridge/. The ebuild
passes -DWITH_STRICT_BUILD_OPTIONS="yes", which swaps the tolerant
find_package_wrapper for the REQUIRED one -- so every devendored library is a
configure-time FTBFS rather than a warning. 3f252c6cd already met this with
ceres ("blender removed its bundled copy between the releases"); draco and
meshoptimizer are the same event, one release later.

1. src_prepare died on a file the 5.2 tarball does not contain.

Until 5.1 Cycles dlopen'd HIP-RT through a generated wrapper,
extern/hipew/src/hiprtew.cc, carrying the literal "libhiprt64.so". Because
dev-libs/hiprt installs into a slotted prefix that is not on the ld.so path,
the ebuild rewrote that string to an absolute path.

5.2 deleted the wrapper and links the library for real:
device/hiprt/device_impl.cpp calls hiprtCreateContext() directly and
intern/cycles/device/CMakeLists.txt:171 appends $. Nothing
replaces the sed, because -DHIPRT_ROOT_DIR (already passed, src_configure)
is now the whole mechanism: FindHIPRT.cmake searches it under the
lib64/lib/bin suffixes, which is exactly where dev-libs/hiprt's
install-path patch puts libhiprt64.so, and cmake.eclass forces
CMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE so the directory lands in the RPATH.

Worth naming because it decides who was affected: the sed sat OUTSIDE any
`if use hiprt`, at the tail of src_prepare. It ran on every merge. USE=-hip
-hiprt failed identically.

Every other `sed -i` target in the ebuild was checked against the tarball.
The remaining eight all exist (Doxyfile is relative to a cd into
doc/doxygen). hiprtew.cc was the only casualty.

2. and 3. draco and meshoptimizer are gone from extern/ and exist in neither
::gentoo nor this overlay.

Both default ON (CMakeLists.txt:500-501) and both are strict-REQUIRED, so
the package stopped at the first of them. Rather than discover them one
rebuild at a time, the cmake line was lifted out of build.log and re-run by
hand with both flags at "no": that configured clean, which bounds the
damage at exactly two and rules out a fourth.

Turning the flags off was the cheaper fix and is not the one taken here.
WITH_DRACO/WITH_MESHOPTIMIZER drive Draco and meshopt compression in the
glTF 2.0 importer and exporter -- a user-facing feature, and "not useful to
the maintainer" is not an exclusion criterion.

Neither library is version-pinned by the source: both find_package_wrapper
calls in platform_unix.cmake pass no version, so the atoms carry no floor.
build_files/build_environment/cmake/versions.cmake names 1.5.7 and 1.1, but
that file is what blender builds for its OWN precompiled bundle and is the
known-bad source of floors that 3f252c6cd had to undo. draco 1.5.7 happens
to be the current release; meshoptimizer is packaged at 1.2, not the 1.1 the
bundle pins.

WHAT THE NEW PACKAGES HAD TO GET RIGHT.

media-libs/draco-1.5.7 must keep libdraco.a. In cmake/draco_install.cmake the
install(TARGETS draco_static EXPORT dracoExport) call is unconditional, so
draco_static belongs to the exported set even at BUILD_SHARED_LIBS=ON.
Reproduced rather than assumed: deleting the archive from a staged prefix and
re-configuring a consumer gives "The installation package was faulty and
contained .../draco-targets.cmake but not all the files it references". The
ebuild says so where someone deleting it would look. SLOT="0/9" is the SONAME,
which cmake/draco_build_definitions.cmake decides via LT_CURRENT/LT_AGE and
which moves independently of $ -- the autoupdate record carries that
warning, since a version bump alone is blind to it. RESTRICT="test": the
release tarball ships third_party/{googletest,eigen,filesystem,tinygltf} as
empty submodule stubs, so DRACO_TESTS cannot be satisfied from it at all, and
DRACO_TRANSCODER_SUPPORTED is off for the same reason. One patch: upstream's
draco.pc installs with relative -Iinclude / -Llib64. It is a patch rather than
a sed on purpose, so a bump that moves cmake/draco.pc.template fails loudly in
src_prepare instead of silently reverting the fix.

media-libs/meshoptimizer-1.2's shared-library switch is not BUILD_SHARED_LIBS;
it is MESHOPT_BUILD_SHARED_LIBS, and it defaults OFF. Without it the package
installs a static archive alone, which is useless to blender, whose
intern/meshoptimizer_bridge is itself a SHARED library.
MESHOPT_STABLE_EXPORTS stays OFF: ON hides the ten MESHOPTIMIZER_EXPERIMENTAL
entry points behind the visibility preset, and they are API consumers call.
The SONAME carries the full version (SLOT="0/1.2", MESHOPT_SOVERSION=$)
because upstream ships an unversioned .so otherwise while stating those same
experimental APIs are not ABI-stable across releases -- a consumer that was not
rebuilt should fail at load, not mismatch quietly. src_test is hand-written:
upstream registers no CTest tests, the suite is the demo binary run with no
arguments (demo/main.cpp: "if (argc == 1) runTests();"), so cmake_src_test
would have passed without executing anything.

The autoupdate record for meshoptimizer probes /tags with select = "max", not
releases/latest, which inverts the usual rule and is measured: v1.1.1 and
v1.0.1 are tags with no GitHub release, so releases/latest would have reported
v1.1 while v1.1.1 was already out. draco keeps releases/latest, its tag being
a bare semver with no "v".

Both are KEYWORDS="~amd64 ~arm64": portable C++, no arch-specific backend, and
the consumer is ~amd64 ~arm64. Confirmed by pkgcheck, which still names
sci-libs/ceres-solver as the SOLE ~arm64 solution -- the new atoms add none.

VERIFIED, AND THE RUNG NAMED. This host has no sudo, so nothing was merged.
The rung is a chain of staged prefixes: both dependencies built to image/ under
a private PORTAGE_TMPDIR, then blender's own cmake line re-run with
CMAKE_PREFIX_PATH pointing at them (the exported targets are relocatable, they
derive _IMPORT_PREFIX from their own location).

draco >>> Completed installing -> libdraco.so.9 (objdump SONAME agrees
with SLOT), libdraco.a, share/cmake/draco/*, and a draco.pc whose
Cflags/Libs are now absolute
meshopt >>> Completed installing -> libmeshoptimizer.so.1.2 (SONAME
agrees), gltfpack, lib64/cmake/meshoptimizer/*
blender -- Configuring done (4.3s) / -- Generating done (1.4s), where the
same command without the staged prefixes still says "Could not
find draco"; CMakeCache resolves draco_DIR and meshoptimizer_DIR
into the two image trees
bridges ninja lib/libbf_intern_{draco,meshopt}_bridge.so -> exit 0,
NEEDED libdraco.so.9 and NEEDED libmeshoptimizer.so.1.2

So the two bridges compile and LINK against the new packages; this is past
configure, not merely at it. pkgcheck is clean on both new packages and reports
only pre-existing findings on blender. emerge -pv, pointed at this checkout
rather than /var/db/repos/bentoo, resolves all three in order.

NOT covered, and it matters: a full blender compile (hours, and this host
cannot merge its dependencies), and the USE=hiprt path, which needs an AMD GPU
and dev-libs/hiprt installed. The hiprtew removal is justified by reading the
source, not by executing it.

No revbump. src_prepare failed unconditionally, so no machine can be carrying
an installed image of -r1 to invalidate.

Left alone deliberately: gentoo-parity.sh reports 5 md5-cache entries naming a
missing ebuild against a documented floor of 0. They are leftovers of the
autoupdate bumps in 9ca16f867 and 9afdacbf2, unrelated to this change, and
folding someone else's cleanup in here would blame the wrong commit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>