mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Michael Olbrich <m.olbrich@pengutronix.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] PTXdist usescases
Date: Wed, 29 Aug 2018 16:48:32 +0200	[thread overview]
Message-ID: <20180829144832.sodx4vry5lybn3ck@pengutronix.de> (raw)
In-Reply-To: <5ec711ebc50e221641f473327e12a56b965842f7.camel@allegion.com>

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
ptxdist@pengutronix.de

  reply	other threads:[~2018-08-29 14:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-13  7:28 Erwin Rol
2018-08-13 10:19 ` Robert Schwebel
2018-08-13 12:16   ` Erwin Rol
2018-08-13 12:40     ` Robert Schwebel
2018-08-27 16:40       ` Michael Olbrich
2018-08-28 15:27         ` Erwin Rol
2018-08-29  8:14           ` Baeuerle, Florian
2018-08-29 14:30             ` Michael Olbrich
2018-08-28 10:07 ` Baeuerle, Florian
2018-08-29 14:48   ` Michael Olbrich [this message]
2018-08-30  8:05     ` Baeuerle, Florian
2018-08-30  9:41       ` Michael Olbrich
2018-08-30 13:06         ` Baeuerle, Florian
2018-08-30 13:41           ` Michael Olbrich
2018-08-31  8:41         ` Baeuerle, Florian
2018-08-31 10:17           ` Michael Olbrich
2018-08-31 12:03             ` Baeuerle, Florian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180829144832.sodx4vry5lybn3ck@pengutronix.de \
    --to=m.olbrich@pengutronix.de \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox