Phil Blundell <[email protected]> writes: > 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.
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. So if we for a moment imagine that we have moved OE to have sstate based per-recipe staging, we still have the same amount of work to do in the following areas: * Modifying BitBake and OE metadata to handle package-based build-time dependencies * Modifying existing recipes to include package-based build-time dependency information You can see the per-recipe staging as a postive side-effect of the package-based build-time dependency implementation. So why take the detour instead of just doing it? > 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) That is IMO just adding more cruft to OE. Not really what we need. > 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. Sounds better. Also, just as for run-time dependencies, the build-time package dependencies is not necesarely the actual package names, but some provides names, so having a "recipe:package" syntax really does not make much sense. >> > (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. 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 ;-) But as we build-time dependencies are typically in the form of some package "provides", it doesn't really matter if the package is renamed. /Esben _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
