owned this note changed 2 years ago
Published Linked with GitHub

Fully External Toolchains

FreeBSD DevSummit - May 17, 2023

Notes

  • package repos have release_2 snapshot of all pkgs associated with the release, but not necessarily archived
  • generic alternatives mechanism would be nice

Questions

  • if we do a stripped down repo, do we need to keep all of the (transitive) dependencies
  • where does /usr/bin/cc come from
    • symlink to real toolchain?
  • how much do we keep? All packages, times every architecture, becomes a lot of data
  • do we need tiers of ports?
  • could we use a jail and build in it?
  • how do zero trust vendors get internal access to our external toolchain?
    • How do they do it now?
      • It's a bit cumbersome. Would be nice to have a better solution
  • if you are building a dot release and a main release, do they get built with their own toolchains?
    • Yes
  • How do we keep the version of head and the versions of packages for head in sync? - e.g. no breaking ABIs.
  • What would the impelementation plan be for introducing Rust?
    • would need to be deliberate - e.g. scheduler wouldn't be first Rust rewrite

Requirements

  • meta - organize the requirements by languages'features, and versions
  • have a pkg archive, like ftp-archive.freebsd.org
  • need a way to install matching toolchain for a given release, for reproducibility
  • Can we tag the ports release with "this is the release/foo we are going to build"?
  • relax/revisit requirement for building N on N-1/N-2 i.e. may not support building 15 on 13 eventually
    • where does that policy come from? from src/Makefile it says the latest -current is guaranteed to be built on latest -stable.
      • EM: 15 on 13 isn't guaranteed today but we have attempted to keep that sort of case working longer than we require
  • We should keep GCC viable

Motivation / Benefits

  • faster build times
  • use alternate compilers more gracefully
  • support for Rust
    • Be intentional about bringing the entire community on board with Rust. And do this by promoting the clear benefits.
    • Beneficial to FreeBSD project to be ready to take advantage of Rust, and so need to start getting infrastructure in place

Plan

  • Need ability to install base toolchain as binary packages. built by Konrad. not sure if installing packages or untarring them into the jail. but problem is that there is no way to know which ports use c.
  • Need to be able to bootstrap a few packages into system such that poudriere knows what to do with them
  • If we don't modify the jail, we need a way to record which packages need a c compiler. how? dtrace?
Select a repo