Tests broken on Linux

[thekid]

Expect:

$ sh test.sh
Run
✓ OK: `xp com.example.Test' -> com.example.Test
✓ OK: `xp run com.example.Test' -> com.example.Test

Help
✓ OK: `xp' -> xp.runtime.Help
✓ OK: `xp -?' -> xp.runtime.Help
✓ OK: `xp help' -> xp.runtime.Help

Version
✓ OK: `xp -v' -> xp.runtime.Version
✓ OK: `xp version' -> xp.runtime.Version

Dump
✓ OK: `xp -w' -> xp.runtime.Dump
✓ OK: `xp -d' -> xp.runtime.Dump
✓ OK: `xp write' -> xp.runtime.Dump
✓ OK: `xp dump' -> xp.runtime.Dump

Eval
✓ OK: `xp -e' -> xp.runtime.Evaluate
✓ OK: `xp eval' -> xp.runtime.Evaluate

XAR
✓ OK: `xp ar' -> xp.xar.Runner

Negative tests
✓ OK: `xp nih' -> Command not implemented: nih

Exit 0

Result instead:

! ERROR: `/tmp/tmp.T5xjubbX7U/xp com.example.Test' 255: 
Uncaught exception: Exception ([bootstrap] Cannot determine boot class path from .:::.:)
# ...

Works on Mac OS X -> https://travis-ci.org/xp-runners/spec/jobs/106027768

[thekid]

Exception ([bootstrap] Cannot determine boot class

This message is from class-main.php. Looks as if it wasn't using the one alongside the binary in the tempdir but the one from $(pwd) instead. Another Paths.Binary() mess?

[thekid]

Worked around by cd'ing into the temporary directory -> https://travis-ci.org/xp-runners/spec/jobs/106030806

Unfortunately cannot find a good way to deal with this, especially because it's working on my Ubuntu virtualboxes.

[thekid]

Especially because it's working on my Ubuntu virtualboxes.

Ah, got it to break on a fresh one with XP v7.1.0

root@vagrant-ubuntu-vivid-64:/usr/bin# curl -sSL \
  https://bintray.com/artifact/download/xp-runners/generic/setup-7.1.0.sh | sh
XP Runners setup (7.1.0)
(c) 2016 https://github.com/xp-runners/reference/
# ...
Done, runners installed to /usr/bin

vagrant@vagrant-ubuntu-vivid-64:~$ /usr/bin/xp -v
Unhandled Exception:
System.IO.FileNotFoundException: Cannot find [class-main.php] in [/home/vagrant/]
# ...

With added debugging, we have:

vagrant@vagrant-ubuntu-vivid-64:~$ /usr/bin/xp -v
BIN = file:///home/vagrant/xp.exe
#     ^^^^^^^^^^^^^^^^^^^^
#     This is always the current directory

[thekid]

After a bit of research, there seem to be the following vagaries here:

• Inside mkbundle'd applications, Assembly.GetExecutingAssembly().CodeBase always contains the current directory and then the image name. Looking at the C code mkbundle generates, it looks pretty clear: static char *image_name = "xp.exe"; is hardcoded, and passed into mono_main() later on.
• Using Process.GetCurrentProcess().MainModule.FileName works well on the following scenarios:
  • Windows: C:\tools\...\xp.exe
  • Inside the mkbundle'd application: /usr/bin/xp
  • Running with Mono on Linux: /usr/bin/mono /usr/bin/xp.exe: /usr/bin/xp.exe (interesting, I'd expect /usr/bin/mono as seen below)
  • However, this does not work with Mono on Mac OS X or Windows, where it contains the path to mono: /Library/Frameworks/Mono.framework/Versions/4.2.2/bin/mono and C:\Program Files (x86)\Mono\bin\mono.exe (see here and here)
• Seems the right way to deal with this would be to check for bin/mono (or compare codebase and main filename - fails only if we create an app called mono!) inside ....MainModule.FileName and then use the GetExecutingAssembly() approach.

See also http://stackoverflow.com/questions/616584/how-do-i-get-the-name-of-the-current-executable-in-c

[thekid]

✅ Verified:

• It now works on Linux
• It hasn't broken Mac OS X

🎉

[thekid]

✅ Released as 7.1.1