[OE-core] Qt in OE-core

[Trevor Woerner]

On 01/08/14 05:28, Richard Purdie wrote:
> On Tue, 2014-01-07 at 20:23 +0100, Martin Jansa wrote:
>> With PACKAGECONFIGs which can list optional dependencies which aren't
>> included in the the layer itself it's now easier to have recipe with
>> optional qt5 support in oe-core, but qt5 itself in separate meta-qt5.
> What dependencies on other layers does meta-qt5 have?
>
> If the policy is all qt5 things into meta-qt5, the risk is a fairly
> large set of layer dependencies for meta-qt5.
>
> There is some perception I don't like external layers which isn't true. 
>
> What I do dislike is "dependency creep". If the meta-qt5 isn't usable
> without pulling in chunks of meta-oe for example, I'd think that rather
> sad and it might as well move to meta-oe at that point.

Theoretically, which dependencies a given usage of qt5 has depends on
which PACKAGECONFIGs are used. In other words, one OE image or one OE
distribution might want to use OpenGL, while another might decide
against it.

    http://qt-project.org/doc/qt-5/linux-requirements.html

If we did move to breaking more things out into more layers, would the
resulting increase in the number of layers be easier to manage if we
didn't have to depend on the user correctly setting up their
conf/bblayers.conf? I admit I'm not familiar with a large number of
applications of OE/Yocto, but of the 3 of which I am aware (gumstix,
imx53qsb, and internally at Linaro) all have moved to using repo (an
external tool) and custom initialization scripts to better handle
setting up a user's layers and configuration.[1][2]

What if a distro configuration file, an image.bb, a MACHINE
specification, or a layer could specify its dependencies itself? Would
this lead to "DLL hell"[3] or would this be the missing ingredient which
keeps some projects from having to resort to using external tools?

If a distro has the power to decide which UI library to use on which
backend, should it then be up to the distro configuration to specify
which layer(s) to add, and maybe even which branch/commit to use, and
maybe also specify these layers' priority and ordering? Maybe in a
different scenario this decision wants to be handled by the image
configuration instead. In either case, we wouldn't have to rely on
external tools (repo) and manual intervention (hoping the user updates
conf/bblayers.conf correctly) to get our layers right before we can build.

Same goes for meta-qt5. If meta-qt5 has dependencies on specific other
layers, maybe those dependencies could be part of the meta-qt5
definition such that these other layers are pulled in automatically? Or
maybe a specific choice of PACKAGECONFIG would trigger the required
dependency?

Would it be possible to add a step in the build process that uses
bitbake's fetcher to get or sync a project's layers before starting the
process of fetching a recipe's sources based on information collected
from hints in the various configuration files?


[1]
https://github.com/gumstix/Gumstix-YoctoProject-Repo/blob/master/README.md
[2] https://github.com/Freescale/fsl-community-bsp-platform
[3] http://en.wikipedia.org/wiki/DLL_Hell