From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 2AFD4138359 for ; Tue, 3 Nov 2020 18:37:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 66ABCE0AA3; Tue, 3 Nov 2020 18:37:09 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 43FDDE0AA3; Tue, 3 Nov 2020 18:37:09 +0000 (UTC) Received: by mail-ej1-f46.google.com with SMTP id k3so25598824ejj.10; Tue, 03 Nov 2020 10:37:08 -0800 (PST) X-Gm-Message-State: AOAM531Vp5XtcBVzSfAc8NCD6sjbogo30KghXP0jag86tMXXYUfRv1jA pkI0ku07myon1wEupegAPikpnxlyq2Pgmudl5fg= X-Google-Smtp-Source: ABdhPJwU0eFdfTlAxCIMwtY+BigNF3CyaITc04AYDlowf1koDaG7wi7DcNa7FXAncBUwSCuYizzBeFFmYx2NmGzrgDI= X-Received: by 2002:a17:906:13d4:: with SMTP id g20mr9654671ejc.206.1604428625098; Tue, 03 Nov 2020 10:37:05 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-catalyst@lists.gentoo.org Reply-to: gentoo-catalyst@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20201103105456.GA3468@dysnomia.localdomain> In-Reply-To: <20201103105456.GA3468@dysnomia.localdomain> From: Matt Turner Date: Tue, 3 Nov 2020 13:36:52 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [gentoo-catalyst] catalyst changes for improving automation To: gentoo-catalyst@lists.gentoo.org Cc: gentoo-releng@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 91ca68d3-6424-4f68-964e-8c84108eb548 X-Archives-Hash: 5ef388ba8673aebb068caa16b9cde58f 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 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?