BartmanAbyss / vscode-amiga-debug

One-stop Visual Studio Code Extension to compile, debug and profile Amiga C/C++ programs compiled by the bundled gcc 12.2 with the bundled WinUAE/FS-UAE.

GNU General Public License v3.0

312 stars 39 forks source link

Build binutils, gdb, gcc and elf2hunk for Linux #107

Closed petmac closed 2 years ago

petmac commented 2 years ago

Context

Currently the extension only works on Windows. As a long term goal, it would be great if we could have some of the functionality on other OSes like Linux and Mac.

This PR is a baby step in that direction, with minimal impact on folks who currently use the extension on Windows.

Scope

In scope:

Build the required tools for Linux
Provide them for download
Ensure the build stays working

Out of scope:

Building tools for Windows or Mac (Linux was easier)
Building Amiga executables (the built toolchain has not been tested)
Debugging

Issues to resolve

General structure: Are we happy with GitHub Actions?

Are the triggers OK?

Should the build steps be inline in the workflow file rather than delegated to helper scripts?

Should the helper scripts be runnable outside of GitHub Actions?

Should the README be updated to point to the workflow as an example of how to port to other systems?

BartmanAbyss commented 2 years ago

I don't really understand how all this github actions/CI stuff works, but if I read the triggers correctly, it will rebuild GCC/GDB every time a commit in vscode-amiga-debug occurs? That doesn't sound right...

petmac commented 2 years ago

Yes, it was good for me testing the PR but maybe not so good for your day-to-day work.

I would like the CI builds to run fairly often so they don't rot, but it's your decision exactly when that is.

Would nightly be better? We can always change it later.

BartmanAbyss commented 2 years ago

I mean, ideally it should just check if the elf2hunk repo has changed or if the gcc-patch has changed.

petmac commented 2 years ago

Yes indeed. I'm not really sure how to reliably check while keeping the process simple.

Sometimes weird things can cause a CI build to break too, like GitHub changing the installed software on their CI machines.

Even though it's running more than necessary, it should just run in the background and generally stay out of the way unless there's a problem.

BartmanAbyss commented 2 years ago

Have you had a look here? Seems to discribe how ro run only on specific files being pushed. https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions

petmac commented 2 years ago

Thanks, I didn't notice the path matching.

petmac commented 2 years ago

Thank you!