Hi, On Tue, Aug 28, 2018 at 10:07:45AM +0000, Baeuerle, Florian wrote: > 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.
The layer stuff I'm working on may help here. The idea is to basically stack multiple BSPs. Files and rules are searched last to first much like we do this with BSP/platform/PTXdist already. ptxconfig/platformconfig/kernelconfig etc. in the later 'BSPs' are more or less a 'diff' to the same config on the next layer. > 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. Hmm, we have something like this already: The 'platform-opengl' package defaults to Mesa, but you can a platform specific rule in each platform. I used this in the past for Mesa vs. Vivante. > 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. The layers might help here too. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ ptxdist mailing list [email protected]
