Two Stage Package Recipe

Two Stage Package Recipe

[Darcy Watkins]

[-- Attachment #1: Type: text/plain, Size: 1903 bytes --]

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.

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’.

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’.

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).

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.

I suppose there is nothing stopping me from breaking out the python bindings into the same second stage scheme as well just to keep things consistent, but in terms of need, breaking out the java is the priority.

Any suggestions, tips in terms of best practices?   … or please point me to good examples to study.  Thanks!

I am presently working from ‘daisy’ branch.

Thanks in advance.


Regards,

Darcy



Darcy Watkins
Staff Engineer, Firmware

----
Sierra Wireless
http://www.sierrawireless.com
[M1]


[-- Attachment #2: Type: text/html, Size: 3341 bytes --]

Re: Two Stage Package Recipe

[Darcy Watkins]

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]
dwatkins@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.