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
> [email protected]
_______________________________________________
ptxdist mailing list
[email protected]
