[OE-core] Automatically creating tar files for bin_package.bbclass

[Andre McCurdy]

On Tue, Jul 5, 2016 at 3:27 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Tue, 2016-07-05 at 08:12 -0700, Khem Raj wrote:
>> On Tue, Jul 5, 2016 at 1:21 AM, Andre McCurdy <armccurdy at gmail.com>
>> wrote:
>> > On Mon, Jul 4, 2016 at 8:58 AM, Burton, Ross <ross.burton at intel.com
>> > > wrote:
>> > >
>> > > On 4 July 2016 at 16:00, Andre McCurdy <armccurdy at 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.

I think the common case is that you wouldn't want to include source or
debug symbols, so using ${D} directly is still not perfect.

Here's the generate-prebuilt-tarfile.bbclass I'm currently using. It's
certainly not suitable for merging yet.

----

DEPLOY_DIR_PREBUILTS ?= "${DEPLOY_DIR}/prebuilts"

do_genprebuilt[depends] += "pbzip2-native:do_populate_sysroot"
do_genprebuilt[dirs] = "${DEPLOY_DIR_PREBUILTS}/${PACKAGE_ARCH} ${WORKDIR}"

do_genprebuilt() {

    if [ "${CLASSOVERRIDE}" != "class-target" ]; then
        exit 0
    fi

    TARFILE_BASENAME="$(echo ${PN}-prebuilt-${PV} | sed 's/AUTOINC+//')"

    tar --transform "s|^image|$TARFILE_BASENAME|" --owner 0 --group 0
-cvf - $(find image ! -type d | LC_ALL=C sort) | pbzip2 >
${DEPLOY_DIR_PREBUILTS}/${PACKAGE_ARCH}/$TARFILE_BASENAME.tar.bz2
}

addtask do_genprebuilt after do_install before do_populate_sysroot

----

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