Re: We need to do something about build times

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