On Thu, Aug 30, 2018 at 08:05:04AM +0000, Baeuerle, Florian wrote: > Am Mittwoch, den 29.08.2018, 16:48 +0200 schrieb Michael Olbrich: > > 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. > > > Sounds interesting, even though I think I do not yet properly understand how > it > will work. Is it really a diff, or more like an extension? Can I add > additional > packages to an upper layer or can I also deselect them?
It's a diff. If you run e.g. a menuconfig in on layer the it will basically take the config from the lower layer, applies the diff before actually running menuconfig. When you're done, a new diff is created. So each layer can add new packages and enable or disable existing packages. > +-------------------------+-------------------------+ > | | | > | Platform A | Platform B | > | | | > +-----------------+-------+-------+-----------------+ > | | | | <- ptxconfig for each > | App A | App B | App C | application > | | | | > |·················+···············+·················+ > | · · | <- not really shared, > even > | Common packages selected in ptxconfig | though the packages > are > | · · | supposed to be 95% > the same > +--------+--------+---+---+---+---+--------+--------+ > | | | 1 | 1 | 2 | 2 | | | <- collections for a > bunch of > | dev | rls | d | r | d | r | dev | rls | variants > | | | e | l | e | l | | | > | | | v | s | v | s | | | > +--------+--------+---+---+---+---+--------+--------+ > > I would be happy if I could actually share the third layer in above ASCII > drawing. > > That basically is the common stuff that should end up on all images (systemd, > busybox > configuration, etc.). It's supposed to be the same everywhere, but they > cannot be > trivially kept in sync. That should be easy with layers: The base layer contains all the common stuff (for platforms, ptxconfig etc.). After changing something in the base layer you just need to run oldconfig in each App 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. > > That would, however, only work if it would be one package? > For am335x with gpu, I need three packages: the OOT kernel module, a > franken-patched > libgbm and the blobs (libEGL, GLES, libpvr*, etc.). > > When i override platform-opengl through configs/platform-a, then these three > packages' > symbols would end up in my ptxconfig, so my ptxconfig is more or less tied to > my platform. Add platform-opengl and the extra packages to the platformconfig and add the dependencies there. If platform-opengl is enabled in both configs, then any dependencies will be handled correctly. > Besides: is there a way to just "by default" select and install a package for > a given > platform (without having the symbol in the ptxconfig)? Add the symbol to the platformconfig. > > > 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. > > I'm curious, when can we expect it to see them in the ptxdist repository? My current plan is to get this ready for the October release. So if all goes according to plan then the code should hit the repository sometime in September. 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 ptxdist@pengutronix.de
