Ebitengine changes working directory when you have resources?

[hackborn]

Ebitengine Version

v2.6.6

Operating System

• Windows
• macOS
• Linux
• FreeBSD
• OpenBSD
• Android
• iOS
• Nintendo Switch
• PlayStation 5
• Xbox
• Web Browsers

Go Version (go version)

1.21.4

What steps will reproduce the problem?

Given this app and a resources/ folder at the same level as main.go:

package main

import (
	"fmt"
	"os"
)

func init() {
	wd, _ := os.Getwd()
	fmt.Println("init wd", wd)
}

func main() {
}

The printed working directory is to my executable.

If you import ebitengine and run, I.e.:

package main

import (
	"fmt"
	"os"

_	"github.com/hajimehoshi/ebiten/v2"
)

func init() {
	wd, _ := os.Getwd()
	fmt.Println("init wd", wd)
}

func main() {
}

Now the printed working directory is to the executable/resources.

If you renamed your local resources/ dir to something else (like resources2/) and rerun, now the working directory is back to the executable.

What is the expected result?

The working directory is always the path to my executable's parent regardless of whether ebitengine is imported.

What happens instead?

With ebitengine imported the working directory is now the path to my parent + /resources.

Anything else you feel useful to add?

No response

[hajimehoshi]

Now the printed working directory is to the executable/resources.

Could you write the result? What are the results in init and main?

[hajimehoshi]

I couldn't reproduce the issue

% go run .
init wd /Users/hajimehoshi/test/test
main wd /Users/hajimehoshi/test/test
ebit key F1

% neofetch
                    'c.          hajimehoshi@Hajimes-MacBook-Pro.local 
                 ,xNMM.          ------------------------------------- 
               .OMMMMo           OS: macOS 14.2.1 23C71 arm64 
               OMMM0,            Host: Mac15,6 
     .;loddo:' loolloddol;.      Kernel: 23.2.0 
   cKMMMMMMMMMMNWMMMMMMMMMM0:    Uptime: 46 days, 9 hours, 40 mins 
 .KMMMMMMMMMMMMMMMMMMMMMMMWd.    Packages: 77 (brew) 
 XMMMMMMMMMMMMMMMMMMMMMMMX.      Shell: zsh 5.9 
;MMMMMMMMMMMMMMMMMMMMMMMM:       Resolution: 1800x1169 
:MMMMMMMMMMMMMMMMMMMMMMMM:       DE: Aqua 
.MMMMMMMMMMMMMMMMMMMMMMMMX.      WM: Quartz Compositor 
 kMMMMMMMMMMMMMMMMMMMMMMMMWd.    WM Theme: Blue (Light) 
 .XMMMMMMMMMMMMMMMMMMMMMMMMMMk   Terminal: tmux 
  .XMMMMMMMMMMMMMMMMMMMMMMMMK.   CPU: Apple M3 Pro 
    kMMMMMMMMMMMMMMMMMMMMMMd     GPU: Apple M3 Pro 
     ;KMMMMMMMWXXWMMMMMMMk.      Memory: 3434MiB / 18432MiB 
       .cooc,.    .,coo:.
                                                         
                                                         

[hackborn]

Thanks for looking into it -- indeed,

go run .

works fine for me as well. My test app is named "res" and I hit the issue when I do

go build
./res

I simplified the test app above, but without the the ebiten import included my output is

init wd /Users/spaceblack/Documents/dev/go/res

and with it included my output is

init wd /Users/spaceblack/Documents/dev/go/res/resources

Been poking at the source -- I see
internal/glfw/cocoa_init_darwin_m has a function changeToResourcesDirectory but I'm not sure if it's getting triggered, I don't see what's calling glfwPlatformInit. If you have any pointers let me know and I'll look at it.

[hajimehoshi]

I failed to reproduce this even with go build.

Been poking at the source -- I see
internal/glfw/cocoa_init_darwin_m has a function changeToResourcesDirectory but I'm not sure if it's getting triggered, I don't see what's calling glfwPlatformInit. If you have any pointers let me know and I'll look at it.

This logic should be intentional, though this should not happen when the binary is not in a .app directory. I was wondering why this happens in your environment.

glfw/glfw@7302f76

glfwPlatformInit is called at:

ebiten/internal/glfw/init_unix.c

Line 296 in 34cdb20

if (!_glfwPlatformInit())

[hackborn]

Thanks much for the help, unfortunately I don't know anything about macOS dev but after reading up on bundles, so far one thing has caught my eye:

CFBundleGetMainBundle says

CFBundle creates a main bundle whenever it possibly can, even for unbundled apps.

That has certainly been my experience. As long as there is an executable and a Resources folder present (actually I've been using "resources"; I thought macOS was case sensitive but in this case it seems to be ignored) then the parent is identified as a bundle. The go run . command does not return a main bundle with a Resources folder because it is compiled and run from a temp directory without a resources folder.

Of course, none of that explains why you (and presumably everyone else) is not having this issue occur. But based on my reading of the docs, what is happening on my system seems reasonable. Unfortunately I don't see any details around what "creates a bundle whenever it possibly can." All I can find are the rules around bundles, which would seem to exclude my case, and that one line, which is broadly inclusive but not specific enough for me to say I'm seeing what should be correct behavior.

I have another Mac I might try this on, otherwise I can't think of anything to do but try to find more info around how CFBundleGetMainBundle() is working.