[OE-core] couple questions about proper PACKAGECONFIG usage

[Jussi Kukkonen]

On 29 October 2016 at 11:08, Robert P. J. Day <rpjday at crashcourse.ca> wrote:
>
>
>   one or two curiosities(?) i've run across re: PACKAGECONFIG usage,
> and as i'm writing a short tutorial page on that feature, i better
> make sure i understand the nuance.
>
>   first, AIUI, for any recipe, *any* possible flag value that can be
> assigned to PACKAGECONFIG should be accompanied by the actual set of
> values assigned to that ... flag(?). random example: gnutls.inc:
>
>   PACKAGECONFIG ??= "libidn zlib"
>
>   PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn"
>   PACKAGECONFIG[libtasn1] =
"--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
>   PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
>   PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
>   PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib"
>
> so while the default PACKAGECONFIG flag settings are "libidn" and
> "zlib", that recipe clearly(?) defines five possible flags. i'm
> assuming it would be an error for any possible flag value to not be
> accompanied by a corresponding flag setting (not sure of the correct
> terminology here, i better check that).
>
>   next, i've noticed a very small number of recipes that define
> "empty" flag strings, like this from opkg-utils_git.bb:
>
>   PACKAGECONFIG = "python update-alternatives"
>   PACKAGECONFIG[python] = ",,,${PYTHONRDEPS}"
>   PACKAGECONFIG[update-alternatives] = ",,,"      <----- there
>
> that last line clearly represents a no-op in the context of
> PACKAGECONFIG, and i was puzzled for a minute until it occurred that
> the only way it would have value is if it were tested somewhere else
> in the recipe, and sure enough, further down:
>
>   do_install() {
>         oe_runmake PREFIX=${prefix} DESTDIR=${D} install
>         if ! ${@bb.utils.contains('PACKAGECONFIG', 'update-alternatives',
'true', 'false', d)}; then
>                 rm -f "${D}${bindir}/update-alternatives"
>         fi
>   }
>
> so "no-op" PACKAGECONFIG flag settings like that:
>
> meta/recipes-devtools/opkg-utils/opkg-utils_git.bb:PACKAGECONFIG[update-alternatives]
= ",,,"
>
meta/recipes-multimedia/pulseaudio/pulseaudio.inc:PACKAGECONFIG[autospawn-for-root]
= ",,,"
> meta/recipes-connectivity/openssl/openssl.inc:PACKAGECONFIG[perl] = ",,,"
>
> appear to be just a kludgy way to pass a config value to a recipe that
> really just uses the PACKAGECONFIG mechanism to hand it over, without
> using actual PACKAGECONFIG processing, is that a fair way to describe
> that? (put another way, if any recipe defines a "no-op" like that, it
> better test that setting somewhere else manually; otherwise, there's
> no real point to it, yes?)

PACKAGECONFIG provides a means of (en/dis)abling features on a per-recipe
basis. How the recipe accomplishes that is really just an implementation
detail. It would be nice if the upstream project supported the required
configure flags but sometimes it does not. Without knowing the opkg-utils
case in detail I'd guess the best option would have been to add a
"--enable-update-alternatives" configuration flag upstream and making
install work without 'kludges' but that may have been considerably more
work than modifying do_install() in the recipe.

If PACKAGECONFIG sets no configure flags or dependencies and it is not used
elsewhere in the recipe to modify the resulting build or packaging, it is
indeed not doing anything.

>   actually, that might be it for this post ... am i missing any other
> subtleties involving PACKAGECONFIG worth mentioning? another
> PACAKGECONFIG-related post coming shortly, but it's more focused so
> i'll post it separately.

No additional monkey business that I know of.

Cheers,
  Jussi

> rday
>
> --
>
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161031/3d87b10b/attachment-0002.html>