Parameterize the iso_data folder for goalc

[massimilianodelliubaldini]

I hope this is everything I needed, and nothing I didn't.

What's Changed

This update adds a command-line parameter to goalc, --iso-path. Providing a path to a directory like D:\Files\Repositories\ArchipelaGOAL\iso_data\jak1 will inform the compiler to use that directory instead.

Why is this useful?

When combined with --proj-path, the compiler can be pointed to a completely different project folder, given the (mi) command, and immediately begin building from that directory, with everything it needs. This eliminates the need to copy iso_data to multiple data directories.

If a subsequent change to the Launcher is made, each mod could be passed an --iso-path pointing to a single shared folder, allowing mods to each run their own REPL without requiring a copy of iso_data in a subfolder.

Independent testing required!

My local repositories are a little suspect, with a mod, a fork of mod-base, and a fork of jak-project, all on the same drive. My decompiler_out and iso_data folders are in the mod repo, not mod-base nor jak-project. So what I did was make the change in the mod-base fork, point --proj-path and --iso-path to the mod folders, and then ran (mi). The output showed a build starting with no errors.

Then I had to create this PR, which my fork of mod-base is unable to do, so I created a patch file, forked jak-project, then applied the patch there.

All this is to say that it would be preferable if someone could apply this code to their own installation and see if it works. Even I wouldn't take my own word for this.

[OpenGOALBot]

Can one of the admins verify this patch?

[xTVaser]

ok to test

[xTVaser]

Tested the main use-case on the launcher, it seems to work open-goal/launcher#582

Just one suggestion around cleaning up some of the parameter passing changes.

The compilation check failure is a weird one....i cant really explain what's going on there. I would be surprised if it was related to the PR coming in from a fork but that would be my first guess.

• Nevermind i think it makes sense, I think you uncovered a flaw in that test since the binaries are dynamically linked, and this PR changed a function signature. I'll have to fix that. Cherry pick this commit dc957f6

[massimilianodelliubaldini]

With No Paths:

With Proj Path only (note: I have my own copy of iso_data inside this mod directory):

With Proj Path and ISO Path:

Compiling with the last: