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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A556F15800A for ; Mon, 31 Jul 2023 05:02:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EB2D7E0C4E; Mon, 31 Jul 2023 05:02:20 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A4E55E0C4B for ; Mon, 31 Jul 2023 05:02:20 +0000 (UTC) Message-ID: Subject: Re: [gentoo-dev] [PATCH 1/7] eclass/nuget.eclass: introduce new eclass From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Mon, 31 Jul 2023 07:02:16 +0200 In-Reply-To: <3293c666-6d3c-8aaf-37f7-35020bd3decf@gentoo.org> References: <20230730142647.872-1-xgqt@gentoo.org> <4766db0bfe4ba2b55d74034f83608b8461145808.camel@gentoo.org> <3293c666-6d3c-8aaf-37f7-35020bd3decf@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: 22e0f779-c45c-405e-8dc3-26136d1ad956 X-Archives-Hash: f225340be5a899f0405db0030b382b48 On Sun, 2023-07-30 at 22:19 +0200, Florian Schmaus wrote: > Which problem are we solving by moving away from this towards a slightly= =20 > more verbose construct? The problem was that cargo.eclass ebuilds were taking significant time during cache regeneration and slowing down tools noticeably. No fancy loops required, contrary to your great theory. --=20 Best regards, Micha=C5=82 G=C3=B3rny