tinygo: set cmd.Dir even when running emulators

[dgryski]

This allows compress/bzip2 to pass with -target=wasi

Fixes #2367

[dkegel-fastly]

LGTM. Rescues GOOS=windows tinygo test debug/macho , too!

[niaow]

Huh. . . I actually seem to still get an access error:

panic: open testdata/e.txt.bz2: errno 2

[niaow]

This also seems to prevent wasm (js wasm) from even starting at all, since it seems to use a relative path:

Error: Cannot find module '/usr/lib/go/src/compress/bzip2/targets/wasm_exec.js'

[dgryski]

Hmm.. can we use os.ExpandEnv to handle constructing the path here?

[aykevl]

This also seems to prevent wasm (js wasm) from even starting at all, since it seems to use a relative path:

Error: Cannot find module '/usr/lib/go/src/compress/bzip2/targets/wasm_exec.js'

You are correct, this is a regression.
The easiest solution may be to use the same {root} pattern as is used in CFlags. See for example:

tinygo/targets/nrf51.json

Lines 4 to 8 in 06df319

	"cflags": [
	"-DNRF51",
	"-I{root}/lib/CMSIS/CMSIS/Include",
	"-I{root}/lib/nrfx/mdk"
	],

[dgryski]

Looks like {root} isn't expanded everywhere:

Error: Cannot find module '/Users/dgryski/go/src/go.googlesource.com/go/src/compress/bzip2/{root}/targets/wasm_exec.js'

Where would be the best place to handle that substitution?

[niaow]

It looks like we handle it for CFLAGS in compileopts/config.go when transforming the config values. It might make sense to put it there as well?

[dgryski]

I was starting to look at compileopts.LoadTarget where we already do a bit of munging (for the asyncify extra files, for example). So {root} would get replaced at load time. We might even be able to have that replacement run only at Load time and not have to do it individually for the CFlags and LDFlags.

[dgryski]

tinygo test -target=wasm compress/bzip2 seems to be failing because the file stuff seems to be unimplemented. I've added a patch to replace {root} in the emulator line so the test at least runs now (even if it doesn't pass.)

[dgryski]

This is ready for review now.

Requested changes have been made.

[aykevl]

I was starting to look at compileopts.LoadTarget where we already do a bit of munging (for the asyncify extra files, for example). So {root} would get replaced at load time. We might even be able to have that replacement run only at Load time and not have to do it individually for the CFlags and LDFlags.

Actually, I was thinking we should do it the other way round. I don't think I wrote this down anywhere, but the way I see it is that compileopts.Target is a read-only version of the combined JSON files. We do modify it in defaultTarget but that's essentially generating a similar target struct, just without an underlying JSON file (and is not modified after creation).
So:

• compileopts.Options: command line options and some related things
• compileopts.Target: JSON file, or inferred from the current system (read-only)
• compileopts.Config: combines the two and provides the "true" values in methods, see for example Config.Scheduler() that prefers the command line option, then the one specified in the target JSON file, and falls back to the coroutines scheduler (sidenote: that one should probably be updated).

Anyway, that is the design as I have it in my mind.

[dgryski]

So, should the logic in this PR be moved to compileopts.Config.Emulator() ?

[aykevl]

That would be most consistent with the rest of the code.