replace aero.py with rusty build system

[jwpjrdev]

this implementation will hopefully be faster and more maintainable

important things:

• building aero
• running qemu
• updating ci commands
• updating env commands (gitpod & codespaces)
• optimisation
• rust documentation
• implementing latest features in aero_build from aero.py

note to self: don't forget to add a comment referencing this gist to the logging functions.

[48cf]

i just want to point out that aero used to have a build system written in rust and it was replaced by the python script due to how long the initial build took, primarily because of the fact we download stuff from the internet and it used reqwest if i'm not mistaken, so please consider bringing in the least amount of crates possible :')

[jwpjrdev]

that's the goal! aiming to use the smallest, fastest crates i can find

[jwpjrdev]

won't be working on this until the 1st, ran out of hours on Gitpod 😢
i've written a good portion of it, just can't do anything with it yet

[jwpjrdev]

by the way, currently, just using gumdrop and termcolor. if colour isn't needed, i'll ditch termcolor.

[48cf]

gumdrop seems fine, you can get rid of termcolor as it seems to bring in a lot of winapi bullshit which is basically useless because aero doesn't have first class support for windows and it's a hefty crate (>1 MB), just implement ansi colors yourself with ansi escapes, it's very easy :')

[48cf]

additionally the newer windows terminal support ansi escapes just fine so it shouldn't be a problem, i'm not sure if termcolor gates the winapi dependency behind a feature, but if it does then it might be wise to disable it

[jwpjrdev]

cool, i'll look into that

[jwpjrdev]

looks like it only uses it when the compile target is windows but it's still pretty hefty.
https://github.com/BurntSushi/termcolor/blob/677f98b26a1b52f72303e1c9dfdc9ef68def8014/Cargo.toml#L21-L22

[jwpjrdev]

accidentally started the workspace from master instead of rust-build and had to force push like a fool 🥲

[ghost]

Just a comment, I think it's reasonable to say leaving out Windows/cygwin/etc compatibility for now should probably be fine, since anything WinApi is a massive pain and tends to add a lot of cruft/bloat. I'm going to take a look at what you have, and maybe throw some tests your way :)

[48cf]

Just a comment, I think it's reasonable to say leaving out Windows/cygwin/etc compatibility for now should probably be fine, since anything WinApi is a massive pain and tends to add a lot of cruft/bloat. I'm going to take a look at what you have, and maybe throw some tests your way :)

I totally agree with that comment, the days of MSYS/Cygwin are numbered ever since WSL became a thing (and Windows 7 is EOL.) I don't think crippling our build system just to support exotic setups is a reasonable choice. Let's just keep it simple :^)

[jwpjrdev]

i need to pull some upstream changes but i cba yet