~eliasnaur/gio#27:
Using 'go run' with a different target

Suppose I'm on Linux with X11. At the moment, if I 'go run' an example, it errors, as X11 isn't supported and it tries and fails to connect to a wayland server.

If I start Sway under X11, 'go run' suddenly starts opening windows inside Wayland, which makes sense.

However, once X11 is supported, it would be great to be able to tell 'go run' what available target to use. I imagine that any of these should be possible on my Linux setup above:

  • Native X11
  • Wayland, e.g. under X11
  • WebAssembly, via $BROWSER

Or is this out of the scope of 'go run'? If so, how does it pick what target is appropriate?

Status
REPORTED
Submitter
~mvdan
Assigned to
No-one
Submitted
25 days ago
Updated
20 days ago
Labels
No labels applied.

~theclapp 25 days ago

Would it be possible to compile in support for both X11 and Wayland and choose the appropriate one at run-time?

If not, probably some build tags that denote X11 or Wayland would do the trick. You could set GOFLAGS appropriately to make the right choice for your system automatically. Or possibly the app/gio tool could figure out what's available and build things appropriately.

For wasm, that's GOOS=js & GOARCH=wasm, which you'd need to tell go run explicitly. And then it'd have to serve an index.html page, probably a js page, and the generated wasm, and tell the browser to open the html file. That is, to me, way beyond the scope of go run. But you could script around it. The help for go run says

If the -exec flag is not given, GOOS or GOARCH is different from the system default, and a program named go$GOOS$GOARCHexec can be found on the current search path, 'go run' invokes the binary using that program, for example 'gonacl386exec a.out arguments...'. This allows execution of cross-compiled programs when a simulator or other execution method is available.

and this is how gojswasm_exec runs wasm via node. So you could write a custom go_js_wasm_exec to serve the webpage and open the browser.

~theclapp 25 days ago

Sigh. I hate that there's neither preview nor edit here. So go_$GOOS_$GOARCH_exec, and so on. Or possibly go\_$GOOS\_$GOARCH\_exec.

~eliasnaur 25 days ago

What ~theclapp writes mirrors my thinking: X11 is selected either through a build tag or through runtime detection ($XDGSESSIONTYPE?), depending on how advanced the X11 port is.

The gio tool could function as an exec wrapper for foreign, but supported platforms. In other words,

$ GOOS=js GOARCH=wasm go run -exec=gio ...

would be pretty cool. gio run is also an option.

~dennwc 20 days ago

In the current X11 prototype it tries to connect to Wayland first and if connection fails from the start it falls back to X11. It's not hard to change the code to use an env to force a specific target.

I would propose to avoid build flags for this case because it's hard to predict if the app will be running with Wayland or X11 on different Linux distros upfront. The downside is that it would require both X11 and Wayland headers at build time. I guess I can also add a wayland build flag that will exclude X11 from the build completely.

It will also simplify a gradual transition from X11 to Wayland - the app will just start using the new code path automatically with no re-configuration necessary.

~eliasnaur 20 days ago

I would propose to avoid build flags for this case because it's hard to predict if the app will be running with Wayland or X11 on different Linux distros upfront.

I agree.

The downside is that it would require both X11 and Wayland headers at build time. I guess I can also add a wayland build flag that will exclude X11 from the build completely.

Please do add a nox11 build flag that will leave out the X11 dependencies.

Register here or Log in to comment, or comment via email.