Re: We need to do something about build times

On Tue, Oct 24, 2023 at 1:55 PM Brooks Davis <brooks@freebsd.org> wrote:
>
> 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 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
>