On Mon, 2011-06-13 at 12:52 +0100, Richard Purdie wrote: > Options > ======= > > a) We could introduce some kind of suffix variable ${PKGSFX} which would > contain the variant, maybe in conjuction with BPN instead of PN: > > PACKAGES = "${BPN}${PKGSFX} ${BPN}-dev${PKGSFX}" > FILES_${BPN}-dev${PKGSFX} = "x" > > This has the downside of having to touch the whole metadata and it looks > ugly.
In OE-lite, we have tried out this option a. It works out pretty well, but is ugly, and does to some degree make it more complex to manage simple recipe meta-data. For this reason, next OE-lite version will transition to something more like the option b you suggest. > b) We could try and remap all the variables at BBCLASSEXTEND time. This > would mean remapping PACKAGES and renaming all the package specific > variables such as FILES, SUMMARY, DESCRIPTION, RDEPENDS, RRECOMMENDS, > RSUGGESTS, RPROVIDES, RREPLACES, ALLOW_EMPTY, SECTION and likely others. In next OE-lite version, I have introduce something called "recipe type", which is nothing else than the name from "BBCLASSEXEND", or "machine" for default recipe type. When resolving dependencies, I have introduced a recipe type context. One for DEPENDS for each recipe type, and one for RDEPENDS for the recipe types that is relevant for run-time dependency handling. In recipe meta-data, you can fx. say DEPENDS = "libncurses native:libtool" Based on the recipe type context, the "libncurses" is prefixed with the recipe type of the context, fx. "machine:libncurses" for machine recipe type. To further simplify recipe meta-data, I have introduced some generic prefix aliases. I have "host" and "target", and "host-cross" and "target-cross", which is then mapped to the proper recipe type based on the context. This seems to work out very nicely. I seems effective in reducing the need for recipe type specfic overrides of DEPENDS variables, and makes recipe meta-data much easier to read IMHO. Of-course, OE-lite does only have package based dependencies, and I haven't given any thought to how this would work out for OE's recipe based build dependencies. But perhaps it would also be a good choice for OE. > I knew were were going to have to read through some of those variables > and remap the dependencies but having to totally move them into new > namespaces is a scary thought (but still possible). Hehe. In danish, we have a saying: "Hvo intet vover, intet vinder", which I belive is something like "Nothing ventured, nothing gained" in english. > c) Switch to prepending to PN. This would only break cases where we have > packages which don't start with ${PN} of which there are comparatively > few. We could make the simplifying assumption that all PACKAGES start > with ${PN} meaning that all manipulations would be simple prepends. If > we do this, problems i) and ii) above are no longer an issue. > > Discussion > ========== > > I don't think option a) above is viable and the current plan implies > we'd do b) but its extremely ugly. I'm therefore tempted to look more > seriously at c). The bigger issues would appear to be: > > * It breaks with convention/tradition for OE (xxx-native vs native:xxx) > * It would add the constraint of packaging starting with ${PN} > * It would require changes to the likes of debian.bbclass to account > for package prefixes when performing auto renaming > * It would break a small set of the metadata where packages don't start > with ${PN} (although the class could simply refuse to extend these > automatically). Looking into the future, wouldn't it make most sense to use the solution broadly in OE, to avoid making it even harder to get started with OE? > Things to consider: > > * Would we just do this for multilibs or would we transition native > recipes to the new style of naming? We don't have PACKAGES problems > for native recipes. > * Likewise, would nativesdk transition? Is has more PACKAGES problems > so likely yes, it would make sense to transition. > * Would we stick with "-" as a delimiter or switch to something like > ":"? I decided to switch from "-" to ":", to allow robust translation of non-prefixed dependency names. > Thoughts/suggestions/better ideas welcome... Thanks, Esben _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core