1. ebuild antlr-cpp-4.11.1.ebuild install 2. ebuild antlr-cpp-4.11.1.ebuild clean $ tree -d /var/tmp/portage/dev-cpp/ /var/tmp/portage/dev-cpp/ └── antlr-cpp-4.11.1 └── work_build ├── CMakeFiles │ ├── 3.25.1 │ │ ├── CompilerIdC │ │ │ └── tmp │ │ └── CompilerIdCXX │ │ └── tmp │ ├── CMakeScratch │ └── pkgRedirects └── runtime └── CMakeFiles └── antlr4_shared.dir └── src ├── atn ├── dfa ├── internal ├── misc ├── support └── tree ├── pattern └── xpath This happens due to a weird interaction in cmake.eclass with EAPI 8. When ${S} == ${WORKDIR}, the eclass creates a build dir that is not nested within ${WORKDIR}: >>> Compiling source in /var/tmp/portage/dev-cpp/antlr-cpp-4.11.1/work ... debug: cmake_src_compile: entering function, parameters: debug: cmake_build: entering function, parameters: * Source directory (CMAKE_USE_DIR): "/var/tmp/portage/dev-cpp/antlr-cpp-4.11.1/work" * Build directory (BUILD_DIR): "/var/tmp/portage/dev-cpp/antlr-cpp-4.11.1/work_build" which then causes issues with a subsequent compile, since we have stale old files lying around, breaking the build. Clearly, cmake.eclass is at fault, but portage should be robust enough to remove files outside ${WORKDIR}.
cmake.eclass bug: https://bugs.gentoo.org/889420
We should probably report unexpected files as a bug too.
(I mean, emit error in Portage)
