Add buildtools as a git module to the haiku repository

[miqlas]

From ​https://discuss.haiku-os.org/t/building-haiku-x64-from-within-haiku-x64/9319/41?u=extrowerk

We could put the buildtools as submodule into the haiku tree, jam scripts could be adjusted, so if the user request a 64 bit build on 64 bit, it would automatically check out the buildtools submodule and using that. We can ofc. check for the host variable, if it isn’t Haiku, the build scripts could try the best to set everything up accordingly. This would mean extra complexity in the buildscripts, probably we don’t want that because maintenance.

According to PulkoMandy: "Actually, that would be great, because currently if you want to build an old version of Haiku, you have to “guess” which version of buildtools is needed (by looking at commit dates). Would you mind creating a ticket on the bugtracker for it?

It’s also possibly a nice easy beginner task for someone who wants to write some bash scripts "

[waddlesplash]

-1 to submodules, they wind up being rather wasteful and make things much slower if you have lots of branches/checkouts/etc.

A better option is just to have configure know what buildtools versions it needs, and check for that. Actually I think it already does, though perhaps it isn't as strict as it needs to be; we could add the git hash of the buildtools repo if we need to.

It's also worth noting that if we move forward with phasing out GCC and switching to Clang, we won't need a buildtools repo at all.

[X512]

Replying to waddlesplash:

It's also worth noting that if we move forward with phasing out GCC and switching to Clang, we won't need a buildtools repo at all.

Buildtools are still needed for GCC2.

[waddlesplash]

Yes, we probably will not switch to clang until after R1, at which point we would drop GCC2.

IIRC, the GCC2 symbol mangling creates clashes between namespaces and classes in instances where GCC3+ ABI does not, so adding it to Clang is probably not worthwhile.

[X512]

Replying to waddlesplash:

Yes, we probably will not switch to clang until after R1, at which point we would drop GCC2.

We can switch GCC4+ to Clang and keep GCC2 as is for now. It can be done soon when build system will be adjusted for Clang. EFI haiku_loader native PE linker can be also used for all architectures.

[waddlesplash]

The build system is already adjusted for Clang

Binutils also supports ARM PE linking, we just need to enable it, so that's not really relevant here.

[X512]

Replying to waddlesplash:

The build system is already adjusted for Clang

Clang build of master source do not produce working image, so more Jamfile adjustments are needed.

[pulkomandy]

Why are submodules "wasteful" please?

Remember that this is a submodule we would very rarely update (buildtools does not get a lot of activity), and you would still get the same "waste" from doing it in configure (everytime you switch to a branch with different version of buildtools, it would re-checkout and rebuild the buildtools).

We can go with a minimalistic approach here, just have the submodule and tell people to use submodule update --init and then run configure pointing to that directory. If you don't want to use it, just don't init the submodule and checkout your buildtools separately, you know what you're doing, no problem. The submodule can be entirely ignored if you don't want to use it.

[waddlesplash]

No, you can bypass the rebuild of buildtools in configure if you know it isn't needed as of right now, and we do make changes to buildtools that do not require a rebuild, e.g. fixing a bug in jam, or adding rules for ARM like you have a patch for now; no need to rebuild x86_64 gcc (or most other architectures) for these. If we make configure rebuild if the hashes don't match, you would then have to spend half an hour (or more, on slower machines) to rebuild the buildtools.

Adding more stringent checks may be good, but making the buildtools locked to a specific commit by configure is just not necessary and will lead to wastefulness.