Install binutils alongside agbcc

[mid-kid]

This was discussed on Discord a while ago, and was prompted by the incompatibility of devkitpro with yet another platform.

I consider the installation of devkitpro to be an unnecessary obstacle, due to the only required component of it being binutils. This is both annoying for the user, and adds unnecessary variability in the users' toolchains, as well as install instructions. A user shouldn't be bothered with figuring out what binutils distribution to use to get their tools.

My hope is that this PR will manage to streamline the installation process and instructions of the gen3 pokemon repositories as well as any other decompilation, and rid them of devkitpro, and other environment-specific makefile code.

In essence, binutils will be compiled alongside agbcc (and libc/libgcc will be compiled with that), when running ./build.sh, and installed when running ./install.sh.

Right now, due to the way the gen3 repositories are structured, you'll have to run make TOOLCHAIN="$PWD/tools/agbcc" to compile the code after installing this version of agbcc. In the long run this will be solved by simplifying the makefiles themselves.

Why this is a draft

It works on my machine, haven't bothered testing in all the different environments we support, as this is quite the boring task. I just wanted to push out a "proof of concept", that should be a minimum working set of changes.

What else could be done to improve the install process

We've discussed in the discord that installing by default into /opt/agbcc (or /opt/pret) might be desireable, as this avoids any issues users are having with installing it into the right directory, and allows them to share the same toolchain across repositories. Of course, this should be expanded with an environment variable for the user to supply a custom location, that scripts and makefiles can pick up on.

Additionally, more things could be added to this bundle, such as for example, build-time dependencies for various pret tools (think libpng), or the pret tools themselves.

Personally, I think it should be considered to somehow make this a full gcc bundle, with preprocessor and gcc frontend, just an older cc1. This will be significantly harder than the current endeavour, and compiling GCC both takes significantly longer and some more build-time dependencies, but will rid us of the last string of platform-dependency that might differ in behavior: the preprocessor. Alternatively, figure out how to build the preprocessor without the rest of GCC. In either case, this would rid us from having to gather a build of GCC for Mac, just for the preprocessor.

As a last note, in case the bundle grows too big or starts taking too long to compile (or needs too many dependencies), it can always be considered to ship a prebuilt bundle for the most common platforms/environments. Binutils and GCC are both very light on system requirements, and builds of them are usually fairly portable, even to different linux distributions.

[mid-kid]

Added a patch to default installing in /opt/agbcc, while making sure the directory is accessible.

[rawr51919]

Was this already resolved by #37?

[mid-kid]

No. You still need to get binutils from a separate source, which involves devkitpro on some platforms.

[rawr51919]

I can see why this one's still here then, it'd be a huge convenience once this is taken care of

[mid-kid]

Addressing feedback:

We already don't need devkitpro

It's still necessary on some platforms and build environments. The idea here is consolidating the install instructions across build environments and reducing the friction of the installation instructions and differences across build environments.

The change of installation path will break all repositories

install.sh would still accept a custom installation path, to avoid breaking existing repositories. This is to ease migration until the install instructions are adapted and search the new environment variable/path is searched by the makefile.

Building binutils is slow

Adding anything to build in this repository will be slow, this is unavoidable. However, I don't believe the increase in build time would be a dealbreaker for most people, as it just needs to be done once.
But just in case, there should be an alternative script to build with system binutils, to allow the option.
For CI and similar systems that need to rebuild on every run, there should be prebuilts of the toolchain. Binutils barely has any dependencies (only zlib, which is bundled), so setting this up won't be very hard.

[rawr51919]

This also needs rebased to fix merge conflicts