Open bcampbell opened 4 months ago
Hi, I don't have any plans on doing this as it increases maintenance work, but of course you can just use the build instructions from the README to build the compiler yourself, or set up a CI job that extracts the necessary files from the released .vsix files
Fair enough - I figured it was a long shot :-) Is the compiler patch kept in sync? The patch references gcc-12, but I thought the current target is gcc 13?
The patch hasn't changed since gcc 10, and it's less than 10 lines anyway. If you don't want to build the compiler yourself, just extract the binaries from the latest .vsix file (it's just a ZIP file) from the Releases
page. I'm sure that can even be automated with a few lines of scripting.
I'm using it directly from the extension right now, but there's something rather satisfying about seeing gcc bootstrap itself, so I'll probably build it myself some time, and maybe even throw together a script to automate it all (eg including elf2hunk and any other extra bits needed). Thanks for the template project, btw! The main.c was a fantastic reference for getting my own code up and running and saved me having to dig through my own old 68k projects to see how to do it...
Check out the CI scripts in the repo, they already automate this for Linux and MacOS. Am 21.02.2024 um 21:19 schrieb Ben Campbell @.***>: I'm using it directly from the extension right now, but there's something rather satisfying about seeing gcc bootstrap itself, so I'll probably build it myself some time, and maybe even throw together a script to automate it all (eg including elf2hunk and any other extra bits needed). Thanks for the template project, btw! The main.c was a fantastic reference for getting my own code up and running and saved me having to dig through my own old 68k projects to see how to do it...
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
Would there be any interest in separating the patched compiler, tools and gcc8_support etc into a separate project? Seems like there's a reasonably natural boundary between the toolset and the vscode extension which uses it, and it might make the toolset more approachable to non-vscode users.
Personally, I'd just love to be able to easily drop in the commandline tools to quickly port an existing (non vscode) game project to amiga. Most other platforms I support (nds, megadrive, pce, cx16, sdl2...), setting up the environment is usually just a case of adding an appropriate bin directory to the path. I can kind of do that at the moment using the binaries in the installed extension, but it feels a bit messy having a path like:
EXPORT PATH="$PATH:$HOME/.vscode/extensions/bartmanabyss.amiga-debug-1.7.7/bin/linux/opt/bin:$HOME/.vscode/extensions/bartmanabyss.amiga-debug-1.7.7/bin/linux"
...Things like issue #53 would also help - having to include the support code in every project is just a tiny extra bit of friction that could be smoothed off.