Evaluate dropping buildtools repo

[kallisti5]

Currently we have GCC (and binutils) in the following places:

• git.haiku-os.org/buildtools
  • Cross-tools used to build Haiku on Linux, etc
• haikuports/.../gcc
  • Used for gcc hpkg packages included in @release/@nightly/etc images
• haikuports.cross/.../gcc
  • Used to bootstrap gcc hpkg packages included in @bootstrap image

The haikuports gcc11 package has kind of drifted away from git.haiku-os.org/buildtools (it used to be based on it). git.haiku-os.org/buildtools represents the "real" core toolchain.

We might want to consider migrating the buildtools packages into a set of gcc_source / binutils_source packages the build process could pull down.

Considerations:

• Does this make things easier or harder?
• How do you bootstrap a new architecture?
• We need the rest of our gcc patches merged upstream to make this viable.
• Haiku's binutils patches have already been accepted upstream.

[kallisti5]

More considerations... we would need to move jam's source code into haiku's repo vs buildtools/jam to complete this (or break it out to git.haiku-os.org/jam)

(You can't pull jam_source if you don't have jam to run the build)

[pulkomandy]

The buildtools repo should remain for the legacy buildtools (gcc2 and corresponding binutils). We can also probably keep jam there.

What we could ocnsider removing is the modern gcc and binutils, and instead have them as an official release archive + a set of patches to apply above it, making things closer to the haikuports way to handle things. It would then be easier to keep things in sync with haikuports, and it is probably a better way to prepare our changes for upstreaming.

Also note that we don't track which version of the buildtools repo is needed to build older versions of haiku (the hrev and btrev tags are independant). So, the "reproducible builds" argument doesn't really hold.

[tqh]

Can't we have gcc8 git repo and a gcc11 git repo instead and base haikuports on the repos?