On Fri, 2011-03-18 at 06:29 +0100, Esben Haabendal wrote: > Yes, I get your point. You could of-course still specify build > dependencies using recipe names/provides, and then just unpack all > target packages build by that recipe. > > This would give you the major part of the KISS win I see, except for in > the dependency handling code of BitBake (and in the learning curve of OE > developers). Keep in mind that by using packages for build-time > dependencies, the mechanism is exactly identical for run-time and > build-time dependencies. Exactly the same code in BitBake handles both, > and the same mechanism needs to be understood. This is also part of the > KISS win of doing it this way.
Right. So, it seems to me that the appropriate way to attack the problem in OE is to start by doing exactly that: leave the syntax of DEPENDS alone for now, treat each entry in DEPENDS as meaning "all packages built by the named recipe", and then implement the per-recipe sysroot construction that I think we are agreed is highly desirable. Then, as a later refinement, we could introduce a mechanism for specifying dependencies more precisely, at the package level rather than the recipe level. We could do that either by extending the syntax of DEPENDS, something like: DEPENDS = "boost:boost-iostreams" (to say that you wanted just the boost-iostreams package from the boost recipe) or, alternately, by introducing a new variable which would either supplement or replace DEPENDS. Either of those would allow us to migrate to fine-grained dependencies without breaking existing recipes. > > (How) do you deal with library package renaming in OE-lite? > > What exactly do you mean? (We are doing several things with library > package naming...) 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. p. _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel