Ühel kenal päeval, K, 16.02.2022 kell 19:39, kirjutas Ulrich Müller: > Function vala_src_prepare did not call eapply_user, so it could not > be > used as a stand-alone phase function but must be called explicitly. > Rename it to vala_setup, which can be called either from pkg_setup or > from src_prepare.
Just to clarify the reasons to drop the EXPORT - it's really about the fact that you can actually never use it automatically. Absolutely all packages that use vala.eclass need to define their own src_prepare in the ebuild anyways, in order to also call gnome_src_prepare, cmake_src_prepare, or xdg_src_prepare. So the exported phase had no value, as an ebuild author always needs to declare their own, so it's just confusing with the vala_src_prepare function naming from before. There may be some value in trying to do these steps in an exported pkg_setup instead, similar to the python eclasses (and what vala.eclass does is very similar to what the python eclasses do). But I fear it would just clash with python_pkg_setup then instead in many cases, as we get a lot of python-any-r1.eclass inheriting lately in meson + vala packages due to the python-exec[-native-symlinks] tinderbox runs. Though things are slowly moving away from needing this (meson added a gnome postinstall step that takes care of it natively, instead of needing custom python postinst scripts), so it'll probably get rarer to need python-any-r1 + vala together and a vala_pkg_setup might be of good value. Anyhow, enough of my rambling here. If someone would like to explore this option, great. If not, I think we should just get it to EAPI-8 with these changes and revisit with EAPI-9. Mart
signature.asc
Description: This is a digitally signed message part
