[Re: [oe] Splitting meta-oe?] On 18.02.21 (Wed 09:20) Tom Rini wrote: > On Wed, Feb 21, 2018 at 09:02:53AM -0500, Joe MacDonald wrote: > > [Re: [oe] Splitting meta-oe?] On 18.02.21 (Wed 11:22) Martin Jansa wrote: > > > > > There is good example of inter-layer dependencies from real world: > > > http://lists.openembedded.org/pipermail/openembedded-devel/2017-February/111447.html > > > > > > Do you want > > > A) new git repository meta-libio-socket-ssl-perl so that meta-networking > > > will depend on this on instead of whole meta-perl > > > B) meta-ddclient which will probably depend on both meta-perl and > > > meta-networking > > > C) ddclient and its dependencies in meta-perl > > > D) libio-socket-ssl-perl moved to oe-core, so that next time we can say > > > that oe-core is just like old oe-classic just with a bit less stuff in it > > > > > > Neither of these options is ideal, but meta-networking getting meta-perl > > > dependency is the one which causes fewest issues to OE users. > > > > Yeah, I've been thinking about this and trying to decide what is the > > "right" thing to do here. Because I already have added layer > > dependencies in meta-networking that I didn't originally envision, so > > what's one more that is, as you say, almost certainly in the majority of > > consumers' projects anyway? But it does force a new layer dependency on > > consumers of the meta-networking layer who may not care about ddclient, > > and I'd like to avoid that if possible. > > > > Honestly, now that I'm back from my vacation, I think the right thing is > > to add the dependency and then start thinking about a way to specify > > layer dependencies with greater granularity than on a meta-layer basis. > > Like, there's no question meta-networking depends on core. It's > > nonsense to think of it without that dependency. But it'd be nice to be > > able to specify a layer dependency that only exists if your project > > includes specific recipes out of that layer. > > > > But that kind of mechanism seems highly prone to breakage and likely to > > be highly contentious even if it was shown to be reliable, so it may not > > get beyond a "that'd be nice" thing for me. > > > > Unless someone else has already implemented it and I'm just not aware of > > how to use it? :-) > > One thing I've been thinking about is that some layers need more > sub-layers. Taking a very tiny peek into meta-networking, perhaps > re-organize into meta-networking-core, meta-networking-iscsi, > meta-networking-vpn, etc. Or maybe that won't help with dependencies. > But the need for layer X for a single recipe can sometimes I think be > solved by re-thinking the layer.
I really like that idea. We effectively started that with the netkit stuff when Armin first submitted it, so making it more formal isn't a big step anyway. > All that said, it might be better instead to add something like > RECIPE_LAYERDEPENDS so that for the one-or-two offs, the recipe will > fail to build (and implement that similar to the logic in > image-container.bbclass? so that you only get a failure on building that > recipe rather than anything in the layer) ? Yeah, that's kind of what I'd been thinking. In the short term, though, the reorg you suggested above sounds *very* appealing to me at first glance. Might be a "let's do both" situation. -- -Joe MacDonald. :wq
signature.asc
Description: PGP signature
-- _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel