Cross-platform support

[grahambates]

Adds Mac/Linux support per issue #106.

Includes FS-UAE fork which ports WinUAE GDB remote debugger implementation.

Binaries for all 3 platforms are bundled and grouped into subdirectories. This is the simplest approach but does have an impact on the VSIX bundle size (~205MB vs ~70MB current size). An alternative would be to have the extension dynamically download platform specific binaries on initialization, similar to vscode-amiga-assembly. Happy to discuss and implement this if required.

Template project is updated to make task config and Makefile cross-platform compatible.

[BartmanAbyss]

First of all, thanks very much for doing the work for this. However it seems, that both github.com as well as the github extension in VSCode can't handle pull requests with such a large number of files. I couldn't find a changed amigaDebug.ts and the changed template project. Did you also document somewhere how the binaries were built so this can be reproduced? Maybe you could split up this PR into 3, one for each platform? ideally, the first one should just move the win32 binaries around and include the source changed, and the other ones containing the respective new platform binaries.

From what I could see, I don't think we need the install-tools directories and contents, so they could be deleted, also the plugin directories with all that ADA etc. stuff aren't needed. What's with the data-directory/guile stuff? is this really needed?

[grahambates]

Yeah I can see the diff is too big to view in the PR. It cuts off after a max file count which is why you can't see amigaDebug.ts etc. You can filter by directory with the Git CLI e.g. git diff -w master..cross_platform src but I agree this is a pain. I'll redo the PR with separate commits.

The binaries were built using the existing CI scripts locally on my Mac and in a Debian VM. I'm still not 100% clear why this solved the multiple of 4 error, but I'll try to get to the bottom of this and get them building correctly in Github Actions.

I'll have a go at cleaning up any unused files. Realistically it's the binaries themselves that take up the most space e.g. m68k-amiga-elf-lto-dump etc. It would make sense to prioritise removing anything non-essential here. Do you think it's safe to remove anything which isn't used by the extension? The data-directory/guile thing was giving warnings when starting GDB as it was trying to reference this relative to the absolute path of the CI build dir. I guess we could let it complain if it doesn't break anything!

[BartmanAbyss]

Yeah, I'm not the best at knowing exactly what's essential and what not regarding the gnu tools, but cleaning out those extra directories seems like a simple thing. It may not reduce the overall size by that much, but it does cut down on the number of files. If you're using the CI scripts anyways, maybe you could add the cleanup to them as well?

[BartmanAbyss]

I think you can definitely get rid of the data-directory. At least I didn't need it on Windows.

[grahambates]

Ok I've split this up into mutliple commits for each logical step. You can view the diff for each one individually by clicking on them in the Commits tab.

I was able to remove quite a lot of files with apparently no impact. I agree it makes sense to add this the the CI scripts. Another change I made was to add the --without-guile option to the configure scripts to silence the warnings about data-directory.

[BartmanAbyss]

Thanks. looks good so far. I just noticed shrinkler's linux binary is called Shrinkler, but the mac binary shrinkler. Is this a problem? I don't know if MacOS has case-sensitive filenames.

[grahambates]

I don't know if MacOS has case-sensitive filenames

The default filesystem is not case sensitive but you can choose others that are. I'll rename it.

[BartmanAbyss]

Did you just compile the regular Shrinkler version? Get the one from my github as it added features such as size profiling.

[BartmanAbyss]

Test results from my Ubuntu 22.04 installation (x64):

• [x] Template project build
• [x] Disassemble ELF file
• [x] EXE2ADF
• [x] Profile File Size
• [x] Shrinkler
• [x] shrinklerstats
• [x] debug (FS-UAE won't run, see comment above)

[grahambates]

Did you just compile the regular Shrinkler version? Get the one from my github as it added features such as size profiling.

Yeah I think I must have. I'll use yours.

[grahambates]

Can we do static linking or how is this working on Linux?

I must have previously installed this package. You should be able to manually install it for now for testing: sudo apt install libsdl-ttf2.0-0.

I'll look into static linking or potentially bundling the .so file.

[BartmanAbyss]

I must have previously installed this package. You should be able to manually install it for now for testing: sudo apt install libsdl-ttf2.0-0.

I think I'll hold on on that as to be able to test the static/bundled version.

[grahambates]

Things should be ready for re-testing now:

• make clean working on Windows
• using correct version of Shrinkler
• FS-UAE runs on Linux without additional dependencies

[BartmanAbyss]

shrinklerstats now work correctly.

[grahambates]

Ok I think I figured out the problem. Setting the env option for child_process.spawn completely replaces the default process.env that it inherits from the current process. In my head it was adding additional variables. Wiping out the existing vars was preventing it from attaching the window to the current display. In my case setting DISPLAY=:0 fixed it but it looks like it caused more problems on your machine. It's now appending LD_LIBRARY_PATH to the default env vars.

[BartmanAbyss]

Ok. profiling seems to work now. on my first attempt it gave me an error "invalid thread id 1", but on the second try it did work.

[BartmanAbyss]

maybe it's a little flakey because of my underpowered linux pc..