Created attachment 682576 [details, diff] fix Makefile.target for _OBJ expansion Hello, After switching to sys-devel/make-4.3, the compilation of media-video/aegisub-9999 fails with unresolved dependencies due to not built .a libraries (below there's an example about libaegisub.a). The problem is in Makefile.target, reported by https://github.com/Aegisub/Aegisub/issues/171 and fixed with https://github.com/wangqr/Aegisub/commit/6bd3f4c26b8fc1f76a8b797fcee11e7611d59a39 (also attached here). (it could be a good idea to set aegisub-9999.ebuild to use https://github.com/wangqr/Aegisub rather than https://github.com/Aegisub/Aegisub , since the former is a fork actively developed) Basically, an implicit rule in Makefile.target cannot be executed, because an unexisting variable is expanded as prerequisites, resulting into an empty string. Long story short, on Gentoo a Makefile rule like lib%.a: $* may expand to /var/tmp/portage/media-video/aegisub-9999/work/aegisub-9999/lib/libaegisub.a: /libaegisub where the pattern stem ‘/libaegisub’ will mean nothing (please, read further about the variable expansion)... https://www.gnu.org/software/make/manual/make.html#Automatic-Variables Taking an example from the GNU make's manual page, a rule like e%t: $* could expand to src/eat: src/a with ‘src/a’ as the pattern stem when the file name ‘src/eat’ matches. We need to discard the directory part of the pattern stem with the automatic variable $(*F) lib%.a: $(*F) This is so the Makefile.target rule .SECONDEXPANSION: lib%.a: $$($$(*F)_OBJ) could expand on the first expansion to /var/.../aegisub-9999/lib/libaegisub.a: $(aegisub_OBJ) and then to the list of aegisub_OBJ object files on the second expansion, so the implicit rule could take action and the prerequisites for libaegisub.a are built. diff a/Makefile.target b/Makefile.target 115c115 < lib%.a: $$($$*_OBJ) --- > lib%.a: $$($$(*F)_OBJ)
Can you make a gentoo PR please? Thanks
(In reply to Nick Sarnie from comment #1) > Can you make a gentoo PR please? > > Thanks I did it now a PR to switch to wangqr repo (this solves also the make 4.3 build failure): https://github.com/gentoo/gentoo/pull/19065 PS: You meant on github, right? ;) Thanks
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=21ffb11f616da44099e8b0b311d5176ede6c7be7 commit 21ffb11f616da44099e8b0b311d5176ede6c7be7 Author: Matthew White <mehw.is.me@inventati.org> AuthorDate: 2021-01-15 12:01:10 +0000 Commit: Nick Sarnie <sarnex@gentoo.org> CommitDate: 2021-01-15 17:10:57 +0000 media-video/aegisub-9999: use wangqr repo to fix make 4.3 build The bug presents itself during compilation as unresolved dependencies. The official Aegisub repo isn't actively updated... That leaves now a problem when make is updated to sys-devel/make-4.3. In Makefile.target it is required to use the automatic variable $(*F), rather than $*, to compile the Aegisub .a libraries with make 4.3. References about make 4.3 bug: - GNU make Automatic Variables https://www.gnu.org/software/make/manual/make.html#Automatic-Variables - Failing to compile on make 4.3 https://github.com/Aegisub/Aegisub/issues/171 - Use target name without directory in $*_OBJ macro https://github.com/wangqr/Aegisub/commit/6bd3f4c26b8fc1f76a8b797fcee11e7611d59a39 Closes: https://bugs.gentoo.org/765133 Package-Manager: Portage-3.0.12, Repoman-3.0.2 Signed-off-by: Matteo Bianco <mehw.is.me@inventati.org> Closes: https://github.com/gentoo/gentoo/pull/19065 Signed-off-by: Nick Sarnie <sarnex@gentoo.org> media-video/aegisub/aegisub-9999.ebuild | 4 ++-- media-video/aegisub/files/aegisub-9999-git.patch | 17 ----------------- 2 files changed, 2 insertions(+), 19 deletions(-)
