Hi, Am Donnerstag, den 30.08.2018, 11:41 +0200 schrieb Michael Olbrich: > 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.
Is there a way to do this so that the (manually?) added symbol survives a "ptxdist menuconfig platform"? > > > > > 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. > Cool, waiting eagerly for it :) Florian _______________________________________________ ptxdist mailing list [email protected]
