Re: Automatically creating tar files for bin_package.bbclass

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2016-07-05 at 08:12 -0700, Khem Raj wrote:
> On Tue, Jul 5, 2016 at 1:21 AM, Andre McCurdy <armccurdy@gmail.com>
> wrote:
> > On Mon, Jul 4, 2016 at 8:58 AM, Burton, Ross <ross.burton@intel.com
> > > wrote:
> > > 
> > > On 4 July 2016 at 16:00, Andre McCurdy <armccurdy@gmail.com>
> > > wrote:
> > > > 
> > > > Say I have a proprietary library which only I can build from
> > > > source
> > > > and I have a conventional recipe which builds it within OE. I
> > > > would
> > > > now like to create a tar file of the library and headers etc,
> > > > plus a
> > > > companion recipe based on bin_package.bbclass to allow others
> > > > to make
> > > > use of the library in their OE builds. ie the situation
> > > > described
> > > > here:
> > > > 
> > > > http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.ht
> > > > ml#packaging-externally-produced-binaries
> > > > 
> > > > Is there a recommended way to create the tar file to support
> > > > that?
> > > > e.g. a class which automatically creates a deployable tar file
> > > > of a
> > > > recipe's ${D} directory?
> > > 
> > > You *may* be able to use package_tar in the recipe in some way to
> > > achieve
> > > this.
> > 
> > It only seems to support creating tar files after packages have
> > been
> > split ( ie individual tar files for each subdirectory under
> > ${WORKDIR}/packages-split ). I don't think it's going to be
> > directly
> > useful for creating a tar file of ${D}.
> 
> package_tar is just another packaging format here so you will get
> individual package separately
> you might want to add another class to package everything into 1
> thats
> a separate issue, you have
> to either add this via a bbclass or additional function

Personally, I think that involving package_tar is likely going to
overcomplicate this, as is packaging up the already separated out
packages.

Better to provide the output as do_install would leave it in ${D}, and
then let packaging happen as the user has configured. Only tricky part
would be the lack of source for the debugging symbols but if you can't
release the source you'd want to "fix" that anyway.

This way you don't need to worry if your tarball matches the users
package configuration options (which backend, which packaging options
etc.).

Cheers,

Richard