From: Erwin Rol <mailinglists@erwinrol.com>
To: ptxdist <ptxdist@pengutronix.de>
Subject: [ptxdist] PTXdist usescases
Date: Mon, 13 Aug 2018 09:28:09 +0200 [thread overview]
Message-ID: <1534145289.32301.5.camel@erwinrol.com> (raw)
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
ptxdist@pengutronix.de
next reply other threads:[~2018-08-13 7:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-13 7:28 Erwin Rol [this message]
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
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=1534145289.32301.5.camel@erwinrol.com \
--to=mailinglists@erwinrol.com \
--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