Currently, PMS specifies the libdir logic for econf command yet doesn't provide a way to obtain the libdir directly. We end up having ebuilds which partially obtain it from EAPI using econf, and partially from multilib.eclass. I believe that PMS should specify explicit get_libdir for improved self-consistency.
Feasible for next EAPI, if an implementation in Portage is ready.
I think we ought to do this along with cleaning up profiles and multilib.eclass, to get a completely consistent behavior. Most importantly: 1. assume 'lib' is the default (matching default autoconf behavior), 2. kill ${ABI:=default} magic in multilib.eclass and the *_default variables. Just teach the things to handle empty ABI, 3. teach the stuff to handle empty LIBDIR_${ABI} and fallback to 'lib'. Then, the algorithm for get_libdir (pretty much based on algo for econf) would be: 1. let libdir=lib 2. if the ABI environment variable is set then 3. let libvar=LIBDIR_$ABI 4. if the environment variable named by libvar is set then 5. let libdir=the value of the variable named by libvar 6. end if 7. end if 8. output $libdir So, the difference would be that econf doesn't pass --libdir when no ABI/value, and get_libdir outputs 'lib'. For completeness, the current mess is: 1. if profile specifies ABI and matching LIBDIR_${ABI}, econf & get_libdir use that, 2. if profile specifies ABI without matching LIBDIR_${ABI}, econf & get_libdir output nothing. I mean, get_libdir gives empty string. Seriously. 3. if profile doesn't specify ABI and ebuild sources multilib.eclass, it sets some random ABI=default, LIBDIR_default=lib, and both econf & get_libdir return the value of $LIBDIR_default, 4. if profile doesn't specify ABI and ebuild doesn't source multilib.eclass, ABI isn't set and econf outputs no --libdir.
(In reply to Michał Górny from comment #2) > Then, the algorithm for get_libdir (pretty much based on algo for econf) > would be: > > 1. let libdir=lib > 2. if the ABI environment variable is set then > 3. let libvar=LIBDIR_$ABI > 4. if the environment variable named by libvar is set then > 5. let libdir=the value of the variable named by libvar > 6. end if > 7. end if > 8. output $libdir AFAICS, this is identical to Algorithm 9 <http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-135002r9> without prefix, and defaulting to "lib" instead of the empty string. > So, the difference would be that econf doesn't pass --libdir when no > ABI/value, and get_libdir outputs 'lib'. Would it be useful for the function to accept an optional argument for the default? That is, "${1:lib}" instead of "lib" in the first line?
(In reply to Ulrich Müller from comment #3) > (In reply to Michał Górny from comment #2) > > Then, the algorithm for get_libdir (pretty much based on algo for econf) > > would be: > > > > 1. let libdir=lib > > 2. if the ABI environment variable is set then > > 3. let libvar=LIBDIR_$ABI > > 4. if the environment variable named by libvar is set then > > 5. let libdir=the value of the variable named by libvar > > 6. end if > > 7. end if > > 8. output $libdir > > AFAICS, this is identical to Algorithm 9 > <http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-135002r9> without prefix, and > defaulting to "lib" instead of the empty string. That's the goal. > > So, the difference would be that econf doesn't pass --libdir when no > > ABI/value, and get_libdir outputs 'lib'. > > Would it be useful for the function to accept an optional argument for the > default? That is, "${1:lib}" instead of "lib" in the first line? I don't know. It could be a little confusing, calling it like 'get_libdir lib64' -- would rather suggest it's supposed to return 'libdir equivalent to lib64'. Another problem I've just noticed is that our get_libdir supports some ancient CONF_LIBDIR_OVERRIDE portage var. Do we want to support that? For reference: get_libdir() { local CONF_LIBDIR if [ -n "${CONF_LIBDIR_OVERRIDE}" ] ; then # if there is an override, we want to use that... always. echo ${CONF_LIBDIR_OVERRIDE} else get_abi_LIBDIR fi }
In EAPI 6: https://gitweb.gentoo.org/proj/pms.git/commit/?id=2377e8895cbf0787220c1468e8d8cec50b65b714
