I took a stab at this and found that the only way I could handle this is to split the package up.
See interspersed with my original email. The short answer is that I had to split it into three package, each with its own recipe. (I may revisit this down the road using classes such as those that are used for having a single package build for target, build a '-native' for the build host and in some cases, for the SDK). -- Regards, Darcy Darcy Watkins :: Staff Engineer, Firmware SIERRA WIRELESS Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main +1 604 231 1100 13811 Wireless Way :: Richmond, BC Canada V6V 3A4 [P4] dwatk...@sierrawireless.com :: www.sierrawireless.com :: www.inmotiontechnology.com On Sat, 2015-01-24 at 08:56 -0800, Darcy Watkins wrote: > Hello, > > > I have a package in my BSP layer, let’s just call it “my-platform”. > At present, it builds libraries to implement a HW access API along > with command line utilities useful for testing and diagnostics (and > using the API from shell scripts). At present, it also uses the > host-swig to generate interface libraries for python bindings and java > bindings to access the HW API. > > > This means that ‘my-platform’ has to depend both on ‘python’ and > on ‘openjdk-7-jre’ to build. > The issue that triggered the need is that openjdk-7-jre has been broken due to something that changed in QEMU so I want to be able to build the base package, then a package for the python bindings and then a package for the java bindings (that I can disable until I have the java build back up again). The objective is to have these handled using dependencies based on what images and/or distro layers call up. For example, my-image-full build everythings but my-image-nojava excludes the java components. > > What I would like to do is to have the default build to the recipe to > build it all EXCEPT for the java bindings. So I would want to build > all the usual libraries and utilities and have this NOT have > dependency on ‘openjdk-7-jre’. > I tried to place these into separate PACKAGEs (i.e. separate RPM outputs). That works great, however I was not able to have outside dependencies select these on individual basis. The build seems to be for all or none. It is like I need to be able to have do_compile, do_install etc. phases for multiple items inside the package, with each chain accessible for dependency rules. > > Then without having to treat it as a different package, I would like > to be able to re-invoke the build to build the java bindings. This > particular step will need to be dependent on ‘openjdk-7-jre’ without > making earlier steps to be dependent on ‘openjdk-7-jre’. > Had to make separate packages: my-platform - for base items python-my-platform - for python bindings to the libraries my-platform-java - for java bindings to the libraries The one-to-many relationship from source to generated outputs is handled by all three recipes retrieving common source. > > I envision that this should result in one RPM output with the first > build products, and the second RPM output with the java bindings > (addons). > I had hoped that this could be handled using a single recipe based on one source retrieval and three generated outputs, but it appears I need to implement it as three recipes. > > In the end, I will want to be able to have a minimalistic image > include and depend on ‘my-package’ without java bindings, and then > have a full feature image that includes and depends on the java > bindings. > Although not as elegant as I hoped, I was able to get this to happen. -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
