From nobody Wed Oct 25 17:00:35 2023 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SFwDK0qzWz4xlGg for ; Wed, 25 Oct 2023 17:00:49 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SFwDJ5Hs2z4f67 for ; Wed, 25 Oct 2023 17:00:48 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-517ab9a4a13so2702a12.1 for ; Wed, 25 Oct 2023 10:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; t=1698253247; x=1698858047; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ABSV+Rw2XdkF39dlQEFU1loJHU0u22gLo4qKxxLYggo=; b=RMGWjxWDqnSCZUSlXnUhwhH3Vx8YxhoirKnv52iF9DF5p0Em+BhhyuY6+uV8pliS6j v/5zBIfTGFzmRvjWTlQbwwEDSty6/p1AEKSA9ASIRP/fU1jAh6X+U2p2C3gdlY3XNg/P o7ea+TOisbtGSr0wME/BlNrOIE3CkHteSm4JM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698253247; x=1698858047; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ABSV+Rw2XdkF39dlQEFU1loJHU0u22gLo4qKxxLYggo=; b=gJlKGdFTxwJpFcvW6l37kXgNRjsm14KyXpLaH3DcNuhcvqtYjDP0jZcWP+UNW52Dj1 XWC/IHQucBjO7gkRgt5VIkEZNl4YXr1SvZ/wiuQW/WRofFE+RqZWzPwNOJuuDPYTquRs ahcxnO6pC+reALmQqGNQ+ZUZIdkvg1RYA9s7GvvClXN8u4VTfonSti3LD7vbnXdEKyEy oe/9eHZQezcgZkjjKNxeZFjI8ciej6zlGytAOlT6iGg3tLlnZnlzlGqKCabU9OQueaOo alTgPVdEAeVCdOf1a4QNtgZeqmd3aoQQrWkaXkSubW7HoAh2kkjHpA4tcmmptLSeGRmn eLrQ== X-Gm-Message-State: AOJu0YxlLjrR7BEtb98VeaTWE6K2Lh9LJL49AO3L6H+Ju9PKQRWhZNut IvkzLWTbNiLIRs/gLMKjnR6Wh4CQmx7hO5AhF6hb0Q== X-Google-Smtp-Source: AGHT+IFaDV4icb2Y4jHZO7iJW/Om7/OvxBpad3lua8NErcst4PxO0u9s5ndzijkz3lQz49UeC1BEAWNLbUfQCCBYZig= X-Received: by 2002:a17:90b:128b:b0:27d:3ed2:86a5 with SMTP id fw11-20020a17090b128b00b0027d3ed286a5mr14386841pjb.33.1698253246609; Wed, 25 Oct 2023 10:00:46 -0700 (PDT) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Kevin Bowling Date: Wed, 25 Oct 2023 10:00:35 -0700 Message-ID: Subject: Re: We need to do something about build times To: Brooks Davis Cc: Robert Clausecker , ports@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4SFwDJ5Hs2z4f67 On Tue, Oct 24, 2023 at 1:55=E2=80=AFPM Brooks Davis w= rote: > > I'll reply to LLVM specific suggestions A big win would be to reduce the number of LLVMs required for common desktop ports. Aside from the base system LLVM, my desktop system seems to build llvm 12, 13, 15. > > On Tue, Oct 24, 2023 at 09:12:13PM +0200, Robert Clausecker wrote: > > - untangle some of the dependencies so that less ports may trigger > > rebuilds of critical ports. For example, llvm docs could be moved t= o > > separate ports so that updates in the documentation toolchain do not > > trigger an LLVM rebuild. > > They are built as of the individual component builds. If there's a way > to build only docs that might be doable with flavors, but I don't have > time to investigate this. > > > - reduce USES to chose lighter dependencies by default. E.g. USES=3Dl= lvm > > could depend on the light flavour by default. I'm sure only very fe= w > > ports need all of LLVM and the light flavour is faster to build. > > That would be great, but without PROVIDES/REQUIRES might be a problem > in practice due to dependency conflicts. If we could figure out > what dependent ports actually need we could consider relegating > features nothing depends on to a "full" flavor. Ideally we'd also have > subpackages so that e.g., users could depend on lldb from the full > package. > > One idea I've started to implement with llvm10 is cutting down the > default set of options for older LLVM ports that are mostly build > depends or to provide llvm libs. The downside is that un-exercised > options will rot as we don't manage to fix them up during base compiler > updates, but we could also prune those entirely after an appropriate > period of time. > > I'd also like to present another idea to better enable binary > dependencies for certain tools: One of the benefits we get from the > base system compiler is that it only changes when you do an OS update. > As we consider entirely external toolchains, that gets lost. I think > there could be value in a middle tier of bits, stored in a separate > package repository (likely with an alternative LOCALBASE) that could > be used for builds. I'd likely include binutils, clang/lld, gcc, and > rust there. IMO we need this if we want to build releases from external > toolchains since we need reproducibility. We actually use something > related in CheriBSD-ports to install aarch64 binaries for some tools > when building CheriABI (memory safe) packages. > > -- Brooks >