Date: Tue, 24 Oct 2023 20:55:20 +0000 From: Brooks Davis <brooks@freebsd.org> To: Robert Clausecker <fuz@freebsd.org> Cc: ports@freebsd.org Subject: Re: We need to do something about build times Message-ID: <ZTgvOCKSehFB-2ZY@spindle.one-eyed-alien.net> In-Reply-To: <ZTgXDSmpAq6lpT3f@fuz.su> References: <ZTgXDSmpAq6lpT3f@fuz.su>
next in thread | previous in thread | raw e-mail | index | archive | help
I'll reply to LLVM specific suggestions 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 to > 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=llvm > could depend on the light flavour by default. I'm sure only very few > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZTgvOCKSehFB-2ZY>