couple questions about proper PACKAGECONFIG usage

* couple questions about proper PACKAGECONFIG usage
@ 2016-10-29  8:08 Robert P. J. Day
  2016-10-31  8:45 ` Jussi Kukkonen
  2016-10-31 10:26 ` Burton, Ross
  0 siblings, 2 replies; 4+ messages in thread
From: Robert P. J. Day @ 2016-10-29  8:08 UTC (permalink / raw)
  To: OE Core mailing list

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

  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.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

^ permalink raw reply	[flat|nested] 4+ messages in thread