Opened 3 years ago
Last modified 3 years ago
#17438 new bug
Evaluate dropping buildtools repo
Reported by: | kallisti5 | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Build System | Version: | R1/Development |
Keywords: | gcc | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
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.
Change History (3)
comment:1 by , 3 years ago
comment:2 by , 3 years ago
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.
comment:3 by , 3 years ago
Can't we have gcc8 git repo and a gcc11 git repo instead and base haikuports on the repos?
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)