Re: rust build requirements

[nia <nia%netbsd.org@localhost>]

On Tue, Aug 13, 2019 at 09:57:44AM -0400, Greg Troxel wrote:
> Should disabling rust-llvm be the default?  (I really have no idea.)

Depends if we run into compat issues and our llvm package is too old or
too new, which was a problem with ponylang. When the llvm package's
version is bumped, or rust becomes dependent on a newer llvm than
whatever we're shipping, there could be problems.

Right now, practically, I notice no difference. Firefox works fine.

If you're building your own packages and are willing to deal with any
potential fallout (i.e. reversing the option and rebuilding if it fails)
it makes sense to disable, currently.

It's worth noting that it's /always/ disabled on SunOS and Darwin.

So maybe it makes sense to make that a universal default and be
extra careful when updating.

On Tue, Aug 13, 2019 at 09:57:44AM -0400, Greg Troxel wrote:
> Perhaps we should patch rustc to use /dev/urandom.

It's already patched locally to use kern.arandom.

The problem is that the bootstrap is a binary.

The actual code is in the rand crate, not rustc. The rand crate has
more consumers than just rustc.

What makes it uniquely problematic for rustc is the amount of times
the initialization code runs.

On Tue, Aug 13, 2019 at 09:57:44AM -0400, Greg Troxel wrote:
> > For LLVM I have the cross-compilation targets (except amdgpu) disabled
> > in PKG_OPTIONS. Even if you plan to cross-compile with LLVM, you probably
> > don't need all of them.
> 
> I wonder what should be default here.

The cross-compilation targets are only on-by-default for x86_64.

For users who want to build everything themselves it makes sense to
disable those targets when they're not using them. Makes less sense
to disable them when we're working on providing binary packages that
are maximally useful.

The logic for not enabling it on non-x86 is probably that those
architectures are seen as weaker (more than a month for a full bulk
build, don't want to be wasting too much time on llvm).