Run task fails if devkitPro is in a drive other than C:

[Clomclem]

Problem:

I was trying this backend, and since i haven't got space left in my C: drive, i installed devkitPro on my D: drive.

When i tried it, the transpile task worked fine, but when i executed the run task, it failed because it was trying to search for gcc
on the C: drive.

I was able to track it to the build.gradle, in which the run task tries to execute gcc from "C:\devkitPro\msys2\mingw64\bin", and subsequently fails if it isn't on that path.

Possible Solution:

I was able to fix it by replacing C: with D: in the build.gradle, so maybe a solution would be to check on various drives to see if devkitPro is there.

Also, using backslash (\) instead of forward slash (/) makes it incompatible with anything that isn't windows.

[TheLogicMaster]

Yeah, on Windows the devKitPro path is hardcoded by default for now. On Linux, an environment variable is set normally during installation, but not for Windows. I plan on either supporting an environment variable that would be manually added or adding a local.properties config option to specify the path if it's not default.

As for the path separators, I may have made mistakes in that particular build.gradle(I'm assuming that you are using the one from the example project), since I've been developing with several similar ones, but different paths are used for Unix and Windows.

Were you otherwise able to get the project working and was the documentation sufficient? I'm a Linux user, so the Windows parts aren't as well tested.

[Clomclem]

Yeah, I did use the build.gradle from the example project.

By the way, apparently gradle (which obviously uses java) supports the forward slash character as a universal path separator, so using it instead of the backslash should work with no issue (see here for more details: https://stackoverflow.com/questions/8663743/is-it-ok-to-use-forward-slashes-instead-of-file-separator-in-my-gradle-build-f).

By the way: I had some other small problems, but they aren’t related to this so I think I’ll open a different issue for that later.

[TheLogicMaster]

Yep, normally forward slashes are fine, but those particular paths are being passed as strings for command line arguments directly, so they don't get normalized.

More testing is definitely appreciated. Running into unimplemented runtime library features like string formatting, garbage collector related crashes, and reflection issues is expected. Debugging crashes more or less requires a C++ debugging setup like CLion to determine stacktraces.

[Clomclem]

Ohh, I forgot that those commands were being directly passed to the command line, you’re totally right!

Maybe you could detect the os and execute a different command for each os (https://stackoverflow.com/questions/11235614/how-to-detect-the-current-os-from-gradle).

Also, I was having compile time errors (apparently its because you need to manually cast some typedef data types to their original type for it to work (i don’t even know if it’s possible to throw an error because of that, I may be wrong so I’ll have to look later)), but again, I think it’s a topic for another issue later.

EDIT: I didn't notice that you already had the os check, good job!