Seen during upgrade from media-libs/gexiv2-0.10.9 to media-libs/gexiv2-0.10.10: <<< obj /usr/share/vala/vapi/gexiv2.vapi Earlier in src_configure() phase: Program vapigen found: NO Program valac found: NO The actually existing tools provided by dev-lang/vala:0.36 are called vapigen-0.36 and valac-0.36, not vapigen and valac.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #0) > Seen during upgrade from media-libs/gexiv2-0.10.9 to > media-libs/gexiv2-0.10.10: > > <<< obj /usr/share/vala/vapi/gexiv2.vapi > > > Earlier in src_configure() phase: > > Program vapigen found: NO > Program valac found: NO > > > The actually existing tools provided by dev-lang/vala:0.36 are called > vapigen-0.36 and valac-0.36, not vapigen and valac. Yep, just looked into that this morning. We could perhaps hotpatch the meson.build in order to look for the available valac/vapigen files. I've been talking with ricots on gnome's irc/#vala and upstream should be getting fixed and I'll backport something for our current version.
Patching of build system of media-libs/gexiv2 and potentially other packages to support new options specifying custom paths to Vala tools would be possible, but I think that it is better to generically fix this problem in vala.eclass. vala_src_prepare() could create symlinks to Vala tools in ${T}/bin and prepend ${T}/bin to ${PATH}.
Created attachment 560938 [details, diff] Patch
Sounds like it would complement my suggestion in https://bugs.gentoo.org/513658#c11 Build system still needs to be fixed though. I think the correct way to support vala is through https://gitlab.gnome.org/GNOME/gitg/blob/master/meson.build#L44 though I cannot find the ebuild for which I looked up how to do this with vapigen. Maybe it's a call from the object returned. Anyway current eclass works fine for every meson ebuilds I bumped up to now and while vala.eclass can sure benefit these modifications, I would not rush them without considering the larger perspective.
The problem was that gexiv2 wrongly tries to look up vapigen and/or valac on its own, ignoring standard env vars that meson itself does honor. I don't see why we should add such workarounds for a single case that's being fixed upstream.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c6c1f1cbd103caf0cceaa21bb4af2e92b4f195b6 commit c6c1f1cbd103caf0cceaa21bb4af2e92b4f195b6 Author: Marty E. Plummer <hanetzer@startmail.com> AuthorDate: 2019-01-16 20:19:56 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-01-16 21:00:11 +0000 media-libs/gexiv2: fix vapi file generation and install Bug: https://bugs.gentoo.org/675294 Package-Manager: Portage-2.3.55, Repoman-2.3.12 Signed-off-by: Marty E. Plummer <hanetzer@startmail.com> Closes: https://github.com/gentoo/gentoo/pull/10850 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> .../gexiv2/files/gexiv2-0.10.10-vala-fixup.patch | 49 ++++++++++++++++++++++ ...iv2-0.10.10.ebuild => gexiv2-0.10.10-r1.ebuild} | 1 + media-libs/gexiv2/gexiv2-9999.ebuild | 4 +- 3 files changed, 52 insertions(+), 2 deletions(-)
I guess that it is sufficient that media-libs/gexiv2 is now fixed.
