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
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
