On Fri, 2011-03-18 at 13:14 +0100, Esben Haabendal wrote: > By doing it this way, I don't think we are getting much closer to the > second step (package-based build-time dependencies). The OE-lite > implementation of per-recipe staging builds on top of package-based > build-time dependencies, so to do it the other way around, would imply > taking the sstate concept and extend it to do per-recipe sysroots. > After that, I believe you have exactly the same amount of development > left to get where OE-lite is in respect to package-based build-time > depencies and per-recipe staging. > > As I see it, package-based build-time dependencies practically obsoletes > sstate.
This is where I think you misunderstand why sstate has been written and what its role is. Its a generic abstraction of taking the output from a task, saving it away somewhere and then being able to reuse a prebuilt version of it. There is no dependency on a package manager, package format or special dependency formats. sstate simply looks for a prebuilt version (matching a checksum), uses it if present, otherwise builds from "scratch". > > I was thinking of situations like the Debian package autonamer, ie the > > thing that causes glibc-dev to come out named "libc6-dev.ipk" or similar > > depending on the soname of the library that was built. It seems like > > this would be a bit awkward to deal with if your dependencies were > > specified purely in terms of output packages. > > As OE-lite is not OE, we are currently not supporting such type of > package renaming. Let's leave that to Debian guys to fight with ;-) What other features are you not supporting? Are you prepared to think about them or is that someone else's problem? Cheers, Richard _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
