Bug 463586 – [Future EAPI] Introduce get_libdir for consistency with econf

• Product: Gentoo Hosted Projects
• Status: RESOLVED FIXED

[Description Michał Górny 2013-03-28 10:07:05 UTC]

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.

[Comment 1 Ulrich Müller 2013-12-18 18:31:41 UTC]

Feasible for next EAPI, if an implementation in Portage is ready.

[Comment 2 Michał Górny 2014-07-02 21:00:13 UTC]

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.

[Comment 3 Ulrich Müller 2014-07-04 15:26:11 UTC]

(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?

[Comment 4 Michał Górny 2014-07-04 15:50:10 UTC]

(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
}

[Comment 5 Ulrich Müller 2015-11-08 21:59:44 UTC]

In EAPI 6:
https://gitweb.gentoo.org/proj/pms.git/commit/?id=2377e8895cbf0787220c1468e8d8cec50b65b714