2014-05-15 12:21 GMT+02:00 Martin Jansa <[email protected]>: > On Thu, May 15, 2014 at 11:16:00AM +0200, Samuel Stirtzel wrote: >> 2014-05-14 21:04 GMT+02:00 Otavio Salvador <[email protected]>: >> > Hello folks, >> > >> > On Mon, May 5, 2014 at 9:21 AM, Otavio Salvador <[email protected]> >> > wrote: >> >> On Sun, May 4, 2014 at 6:47 PM, Martin Jansa <[email protected]> >> >> 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 <[email protected]> >> >> ... >> >>> 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 <[email protected]>' 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 -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
