[oe] [meta-qt5][PATCH] qtbase.inc: Enable accessibility by default

Samuel Stirtzel s.stirtzel at googlemail.com
Thu May 15 11:34:35 UTC 2014


2014-05-15 12:21 GMT+02:00 Martin Jansa <martin.jansa at gmail.com>:
> On Thu, May 15, 2014 at 11:16:00AM +0200, Samuel Stirtzel wrote:
>> 2014-05-14 21:04 GMT+02:00 Otavio Salvador <otavio at ossystems.com.br>:
>> > Hello folks,
>> >
>> > On Mon, May 5, 2014 at 9:21 AM, Otavio Salvador <otavio at ossystems.com.br> wrote:
>> >> On Sun, May 4, 2014 at 6:47 PM, Martin Jansa <martin.jansa at gmail.com> wrote:
>> >>> On Mon, Apr 28, 2014 at 12:27:39PM -0300, Otavio Salvador wrote:
>> >>>> qtdeclarative requires accessibility to be enabled and it is added by
>> >>>> default to the toolchain so we ought to have it enabled to ensure the
>> >>>> default toolchain generation works.
>> >>>>
>> >>>> Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
>> >> ...
>> >>> As I told you on gtalk, I would prefer default to stay as minimal as
>> >>> posible, why don't you change packagegroup-qt5-toolchain-target.bb to
>> >>> use RRECOMMENDS instead of RDEPENDS so that missing
>> >>> qtquickcontrols-qmlplugins package doesn't break it when it's not
>> >>> available (because it's empty)?
>> >>
>> >> I don't have a strong opinion for either case however I think we ought
>> >> to know what other meta-qt5 users think about it.
>> >>
>> >> In support to this patch addition I think we ought to provide the most
>> >> used features of Qt5 working out of box to users have a good first
>> >> use. Special cases can customize it per need basis. I think QML is
>> >> common enough for us to provide full support for it by default.
>> >
>> >
>> > Martin and I have different views on this topic and I'd like to merge
>> > or drop this patch. Could people comment on this one?
>> >
>>
>>
>> We may want to be able to let the user choose between 2 flavors of Qt.
>>
>> One of them could be a standard Qt (which is what I use), other users
>> seem to prefer a stripped down version with some features switched
>> off.
>>
>> As 'Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>' noted on qt-interest [1]:
>> "Apart from this: builds with feature switches are not really tested,
>> so I'm not surprised that [there are combinations that don't even
>> build]. But we totally welcome patches that would fix such builds."
>>
>> So IMO it would be a good idea to have a constantly tested low
>> footprint version.
>>
>> There is no one size fits all in this case, but can we provide 2
>> versions that work for 99% of the users?
>
> What you mean by 2 versions here?
>
> There is simple PACKAGECONFIG option to enable more features (most
> people will probably enable icu, gl* and accessibility).

With 2 versions it is meant that the user has a simple way to select
one of two well tested sets of configurations without knowing the
details/pitfalls of all the configuration entries.

>
> But we don't want 2 qtbase recipes one with more PACKAGECONFIG options
> enabled and other with more disabled.
>

Agreed. Multiple qtbase recipes are a suboptimal solution.

A DISTRO_FEATURES entry could do; although other implementations could
be more suitable.
In cases where a user wants more fine grained control over the
packages, he can still override the PACKAGECONFIG in a .bbappend.


-- 
Regards
Samuel



More information about the Openembedded-devel mailing list