pango: add PACKAGECONFIGs for all the optional dependencies

Signed-off-by: Ross Burton <ross.burton@intel.com>

---
 .../recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

-- 
2.20.1

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

On 10/7/19 9:38 AM, Ross Burton wrote:
> Signed-off-by: Ross Burton <ross.burton@intel.com>

> ---

>   .../recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb | 17 ++++++-----------

>   1 file changed, 6 insertions(+), 11 deletions(-)

> 

> diff --git a/meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb b/meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb

> index b0f565b9b07..b8a89d005e5 100644

> --- a/meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb

> +++ b/meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb

> @@ -7,24 +7,19 @@ LICENSE = "MIT"

>   LIC_FILES_CHKSUM = "file://COPYING;md5=e11f5c3149cdec4bb309babb020b32b9 \

>                       file://src/hb-ucd.cc;beginline=1;endline=15;md5=29d4dcb6410429195df67efe3382d8bc"

>   

> -DEPENDS = "glib-2.0 cairo fontconfig freetype"

> -

>   SRC_URI = "http://www.freedesktop.org/software/harfbuzz/release/${BP}.tar.xz"

>   SRC_URI[md5sum] = "89b758a2eb14d56a94406cf914b62388"

>   SRC_URI[sha256sum] = "c651fb3faaa338aeb280726837c2384064cdc17ef40539228d88a1260960844f"

>   

>   inherit autotools pkgconfig lib_package gtk-doc

>   

> -PACKAGECONFIG ??= "icu"

> -PACKAGECONFIG[icu] = "--with-icu,--without-icu,icu"

> +PACKAGECONFIG ??= "cairo fontconfig freetype glib icu"

> +PACKAGECONFIG[cairo] = "--with-cairo,--without-cairo,cairo"

> +PACKAGECONFIG[fontconfig] = "--with-fontconfig,--without-fontconfig,fontconfig"

> +PACKAGECONFIG[freetype] = "--with-freetype,--without-freetype,freetype"

> +PACKAGECONFIG[glib] = "--with-glib,--without-glib,glib-2.0"

>   PACKAGECONFIG[graphite] = "--with-graphite2,--without-graphite2,graphite2"

> -

> -EXTRA_OECONF = " \

> -    --with-cairo \

> -    --with-fontconfig \

> -    --with-freetype \

> -    --with-glib \

> -"

> +PACKAGECONFIG[icu] = "--with-icu,--without-icu,icu"


Hi Ross,

PACKAGECONFIG has been nagging at me for years.
This is mostly me just blowing off steam but I would
like to hear your opinion.

While this is technically correct and seeing as oe-core is
a distribution building system rather than a distro, this change
makes sense, I do wonder how we're going to keep up with
the testing that such flexibility requires. We could
test each package's default config and then toggle each
PACKAGECONFIG individually, hopefully with an automated tool.

In theory for N PACKAGECONFIGs, we'd need to do not just N
toggles but for pairs of interacting configs: N * N-1 builds
and so on for triplets, quadruplets, etc. For dependencies
between packages, the number of combinations explodes rapidly.

The status quo seems to be that we enable the options, pick
reasonable defaults, and hope that distros and users test their
configs and report errors. That'll work for detecting some errors
even if it can take a while to get feedback. We recently tested
a variety of configurations and found > 30 configurations that
didn't work at all at build time.

So for this package, are there use cases that you know of where
the old, hard-coded defaults are a problem?

It's also interesting to see that the README.md for pango says:

    The Cairo backend is the preferred backend to use Pango with and is
    subject of most of the development in the future.  It has the
    advantage that the same code can be used for display and printing.

    We suggest using Pango with Cairo as described above, but ...

so it would seem that even our defaults are not the ones recommended
by upstream.

Does pango build if you drop glib? The README.md says:
    Dependencies
    ------------
    Pango depends on the GLib library; more information about GLib can
    be found at https://www.gtk.org/.

../Randy
>   

>   PACKAGES =+ "${PN}-icu ${PN}-icu-dev"

>   

> 



-- 
# Randy MacLeod
# Wind River Linux
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

On 07/10/2019 18:44, Randy MacLeod wrote:
> PACKAGECONFIG has been nagging at me for years.
> This is mostly me just blowing off steam but I would
> like to hear your opinion.
> 
> While this is technically correct and seeing as oe-core is
> a distribution building system rather than a distro, this change
> makes sense, I do wonder how we're going to keep up with
> the testing that such flexibility requires. We could
> test each package's default config and then toggle each
> PACKAGECONFIG individually, hopefully with an automated tool.

I don't believe an automated tool for this makes complete sense, as 
several recipes have mutually exclusive PACKAGECONFIGs options. 
Building all of the combinations will by design fail some of the time, 
and that's not even considering other recipes where recipe A may depend 
on recipe B having PACKAGECONFIG foo enabled.

This tooling existing would be useful to easily verify a recipe instead 
of having to do it by hand, but I don't believe it should be part of the 
automated QA process.

> The status quo seems to be that we enable the options, pick
> reasonable defaults, and hope that distros and users test their
> configs and report errors. That'll work for detecting some errors
> even if it can take a while to get feedback. We recently tested
> a variety of configurations and found > 30 configurations that
> didn't work at all at build time.
> 
> So for this package, are there use cases that you know of where
> the old, hard-coded defaults are a problem?

I added the PACKAGECONFIGs for this package because there were some 
already but they didn't cover the range of optional dependencies, and 
most of the dependencies are for the tools and test suite.  If someone 
was slimming a system aggresively, they could disable the bulk of the 
PACKAGECONFIGs and still have a usable harfbuzz library.

There's definitely a balance between flexibility and complication. For 
example, I recently encouraged removal of some PACKAGECONFIGs for 
optional dependencies that have been dead for several years.

> It's also interesting to see that the README.md for pango says:
> 
>     The Cairo backend is the preferred backend to use Pango with and is
>     subject of most of the development in the future.  It has the
>     advantage that the same code can be used for display and printing.
> 
>     We suggest using Pango with Cairo as described above, but ...
> 
> so it would seem that even our defaults are not the ones recommended
> by upstream.
> 
> Does pango build if you drop glib? The README.md says:
>     Dependencies
>     ------------
>     Pango depends on the GLib library; more information about GLib can
>     be found at https://www.gtk.org/.

So there's a little confusion here in that I put "pango" in the commit 
message but the patch was for harfbuzz... v2 incoming.

Our Pango, however, is built with Cairo and Glib (not as a 
PACKAGECONFIG, but explicit DEPENDS).

Ross