public inbox for gentoo-catalyst@lists.gentoo.org
 help / color / mirror / Atom feed
From: Matt Turner <mattst88@gentoo.org>
To: gentoo-catalyst@lists.gentoo.org
Cc: gentoo-releng@lists.gentoo.org
Subject: Re: [gentoo-catalyst] catalyst changes for improving automation
Date: Tue, 3 Nov 2020 13:36:52 -0500	[thread overview]
Message-ID: <CAEdQ38G8zJzLt-oEkwbVuJxjqpkjF5H1wM6hmQBfk18sso-VPQ@mail.gmail.com> (raw)
In-Reply-To: <20201103105456.GA3468@dysnomia.localdomain>

Sorry, I missed one of the questions, but it requires a longer answer anyway.

On Tue, Nov 3, 2020 at 5:56 AM Daniel Cordero <gentoo.catalyst@xxoo.ws> wrote:
> How would a target that depends on a different rel_type work? Forks in
> the dependency tree.

I haven't given that a lot of thought yet, but it's something I would
like to have a plan for.

We build 32-bit and 64-bit systemd and non-systemd stages on SPARC, as
well as a bootable ISO.

32-bit     systemd: stage1 -> stage3
32-bit non-systemd: stage1 -> stage3
64-bit     systemd: stage1 -> stage3
64-bit non-systemd: stage1 -> stage3 -> livecd-stage1 -> livecd-stage2
(We skip stage2)

This means that we have some build chains that are entirely
independent from one another and could actually run in parallel. E.g.,
a 32-bit build could happen at the same time a 64-bit build runs
without any conflicts. Our SPARC system has 256 threads, so it would
like to build in parallel if possible.

Similarly, a stage1 build from one of the 32-bit build chains could
happen in parallel with a stage3 build from the other. We wouldn't
want to run the same type of build concurrently if they share a binary
package cache, because we would inevitably spend CPU cycles doing
duplicate work. E.g., the systemd stage3 build running in parallel
with the non-systemd stage3.

Whether all of those build chains should be specified in the same
".build" file... I don't know. It seems like it could get a bit
unwieldy.

Maybe we could have a top-level ".build" file that references each of
these build chains, described in other files? If we did that, that
would certainly allow us to specify a different rel_type per chain.

I'm not aware of cases where we'd want different rel_types in the same
chain. Do you know of such a case?


  parent reply	other threads:[~2020-11-03 18:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-03  3:44 [gentoo-catalyst] catalyst changes for improving automation Matt Turner
2020-11-03 10:54 ` Daniel Cordero
2020-11-03 18:19   ` Matt Turner
2020-11-04 10:46     ` Daniel Cordero
2020-11-03 18:36   ` Matt Turner [this message]
2020-11-03 13:04 ` Brian Dolbec

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=CAEdQ38G8zJzLt-oEkwbVuJxjqpkjF5H1wM6hmQBfk18sso-VPQ@mail.gmail.com \
    --to=mattst88@gentoo.org \
    --cc=gentoo-catalyst@lists.gentoo.org \
    --cc=gentoo-releng@lists.gentoo.org \
    /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