On Mon, Jul 04, 2011 at 05:49:37PM +0100, Chris Elston wrote: > On Mon, 2011-07-04 at 17:44 +0100, Graeme Gregory wrote: > > On 07/04/2011 05:12 PM, Chris Elston wrote: > > >> Hi, with my Angstrom cap on I like this syntax and I think it will be > > >> really useful. > > >> > > >> A second level concern I have is about conflicting features, its not > > >> something we will come across probably in DISTRO land as we are sensible > > >> enough not to select them. But users could select them in local.conf. > > >> > > >> Graeme > > > As a new developer, I've discovered that there are plenty of things that > > > you can set in local.conf which break things :D > > > > > > Could you please give an example of conflicting features that could > > > cause problems, I'm not experienced enough with OE to have encountered > > > that problem yet. > > > > > > > > Cant think of a solid one off the top of my head, but I mean the cases where > > > > --enable-feature means that --disable-another-feature is done. > > > > This is why I listed it as a secondary issue. > > > > Graeme > > I understand. We could capture that information with an optional extra > field in the config info something like: > > PACKAGE_CONFIG[foo] = "--enable-foo, --disable-foo, libfoo, <options > which conflict with foo>"
Maybe I'm influenced a lot by gentoo, but most options are set with --enable-foo/--disable-foo or --with-foo/--without-foo so shortcuts for such cases would be nice instead of repeating "foo" 3 times on same line. Also again from gentoo world.. can I say in recipe bar.bb DEPENDS = "abc[foo]" or DEPENDS = "abc[-foo]" because if some recipe depends on gstreamer with vorbis enabled it should be easy to say it in DEPENDS then some magic python fce and if someone tries to build it in distribution with vorbis disabled then it should fail with message like "No provider for gstreamer[vorbis]" Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
