Re: [ptxdist] PTXdist usescases

["Baeuerle, Florian" <Florian.Baeuerle@allegion.com>]

Hi,

the way we use ptxdist might be interesting for you as well.

We use one ptxdist directory with two platforms and three applications,
let's call the platforms X and Y, and the Applications A, B and C

Application A with two variants on one platform
 - release [platform X]
 - devel [platform X]
Application B with four variants on two platforms
 - variant-1-release [platform X, Y]
 - variant-1-devel [platform X, Y]
 - variant-2-release [platform X, Y]
 - variant-2-devel [platform X, Y]
Application C with two variants on one platform
 - release [platform X]
 - devel [platform X]

The devel variant is release + gdb, a few other tools and root login.

Application A, B, C each have their own ptxconfig. Each variant has its
collectionconfig. We build the images (squashfs + rauc bundles) with 
image packages under each platform directory.

so for building all images for Application B on Platform X, we do this:

ptxdist images \
    --ptxconfig=configs/app-B/ptxconfig \
    --platformconfig=configs/plat-X/platformconfig

The platformconfig for Platform X has all image packages enabled, but of
course we do not want to build image-platform-X-app-A with app-B's ptxconfig,
so we put some ifs in the image package makefile, where we check for the
currently selected PTXCONF_PROJECT.

What ptxdist misses for our use-case is some sort of collection-like feature
for platform-specific things (such as image packages, or platform-specific
graphics drivers). With the image packages, we use that workaround, but there
could be other use-cases.

Let's say I want to build App D on two platforms, each requiring different
graphic drivers (SGX is a nightmare), I wouldn't really know how to do that
properly.

The problem otherwise could be solved by using one ptxconfig that selects many
many packages as module. That, however, turned out to be a bit too complex,
because there are quite a few differences between the dependencies of App A, B
and C. Further, there are things that are bool instead of tristate that you
might not need/want.


Best Regards
Florian

Am Montag, den 13.08.2018, 09:28 +0200 schrieb Erwin Rol:
> Hello all,
> 
> as a long time ptxdist users I ended up with some (weird) ptxdist uses
> cases, some of wich simply are from before ptxdist offered something
> similar, some others I am not so sure if they are possible with "plain"
> ptxdist. 
> 
> So I thought to ask here to see if others have similar uses cases and
> how they solved them.
> 
> To not get a huge mail with 1000 and 1 topics I start with my most
> important uses case, that is to be able to build separate (squashfs)
> images and also version (via git) those images. 
> 
> For example I build a rootfs image with things like webkit and Qt5
> (both take serious amounts of CPU power and time to build) and version
> that. From ptxdist point of view that is a normal build. 
> 
> But than I use the sysroot-* dirs inside a second ptxdist projects to
> build an "appfs". That only has all software written by my client.
> Those client packages have no ptxdist-DEPS on ptxdist packages like Qt,
> because we know for sure those packages are already build because we
> first build the rootfs.
> 
> This means we end up with two (git versioned) images that will be
> overlaymounted to give the full/final "root" filesystem on the target.
> 
> There are several reasons why I started doing this. 
> 
> - Build times, the rootfs doesn't have to be rebuild when client
> software is changed.
> - Target software update images are smaller when only client software
> (appfs) has to be updated (was important in a time with expensive GSM
> modems, and it is still useful to reduce in field update times)
> - Reuse, the rootfs kan be reused for different projects. 
> 
> It is a bit like the yocto layer system, just that the (two) layers are
> build separately and give their own filesystem images. 
> 
> It has some problems (where acceptable at the time);
> - copying the systemroot-* dirs is a bad hack, and still needs the
> original systemroot-* dirs because of all the absolute paths in the
> files. 
> - the host tools (like cmake) are build twice (in rootfs and appfs)
> which also takes a considerable amount of time. 
> 
> So is there someone that has similar uses cases and if yes how did you
> solve it?
> 
> And would it be an interesting feature for upstream ptxdist (not my
> implementation) ? 
> 
> - Erwin
> 
> 
> 
> _______________________________________________
> ptxdist mailing list
> ptxdist@pengutronix.de
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de