-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split compiler into separate project #253
Comments
Hi, |
Fair enough - I figured it was a long shot :-) |
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 |
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). |
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.
The text was updated successfully, but these errors were encountered: