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)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b6e2235a3982cad4d74bb7eb49e858835344c3ba commit b6e2235a3982cad4d74bb7eb49e858835344c3ba Author: Sam James <sam@gentoo.org> AuthorDate: 2023-06-26 09:54:06 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-07-02 13:23:39 +0000 cmake.eclass: workaround S=${WORKDIR} creating builddir above ${WORKDIR} When S=${WORKDIR}, cmake.eclass would create its build directory (if CMAKE_USE_DIR is unset) above WORKDIR(!) as ${WORKDIR}_build. Creating directories above WORKDIR is not legal. Portage has its own bug (bug #889418) in that it doesn't clean up unknown directories above WORKDIR in PORTAGE_TMPDIR, so combined, you get a problem where "ebuild ... clean" doesn't actually clean things up at all, and you get very confusing issues if e.g. changing CC between runs. The explicit S=WORKDIR check isn't truly needed but it makes explicit our intent here. Bug: https://bugs.gentoo.org/889418 Closes: https://bugs.gentoo.org/889420 Signed-off-by: Sam James <sam@gentoo.org> eclass/cmake.eclass | 9 +++++++++ 1 file changed, 9 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=2b32cb0d67222da271e2ae25b19479f0374648da commit 2b32cb0d67222da271e2ae25b19479f0374648da Author: Sam James <sam@gentoo.org> AuthorDate: 2023-06-26 09:54:06 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2023-09-16 15:03:30 +0000 cmake.eclass: workaround S=${WORKDIR} creating builddir above ${WORKDIR} When S=${WORKDIR}, cmake.eclass would create its build directory (if CMAKE_USE_DIR is unset) above WORKDIR(!) as ${WORKDIR}_build. Creating directories above WORKDIR is not legal. Portage has its own bug (bug #889418) in that it doesn't clean up unknown directories above WORKDIR in PORTAGE_TMPDIR, so combined, you get a problem where "ebuild ... clean" doesn't actually clean things up at all, and you get very confusing issues if e.g. changing CC between runs. The explicit S=WORKDIR check isn't truly needed but it makes explicit our intent here. Bug: https://bugs.gentoo.org/889418 Closes: https://bugs.gentoo.org/889420 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> eclass/cmake.eclass | 9 +++++++++ 1 file changed, 9 insertions(+)
