Running the samples with proper cwd doesn't work any longer

[floooh]

I'm not able to run the samples on OSX, even with manually set current working dir from Xcode, any idea what's up with that @fungos ?

PS: samples that need to load files that is... others work fine...

I also get a compile error on Windows in the samples in examples/common/entry/dbg.cpp, may be the current version of bgfx is a bit unstable...

[bkaradzic]

What's the error? It shouldn't be unstable.

[bkaradzic]

I just built it without warnings. I'm on 10.9.5.

-- The C compiler identification is AppleClang 6.0.0.6000056
-- The CXX compiler identification is AppleClang 6.0.0.6000056

It spews also all compiler commands. I don't remember being like that before?

[fungos]

For the compiler error on windows I've added the missing define here #3.

Now about the error running samples on macos, isn't there anything to do with windowed/cmdline? Is it creating a bundle?

To be sure, I ran here on linux and windows all 25 samples with ./fips run and no problems. But from inside visual studio we need set the workdir as expected otherwise samples that require data crash.

[floooh]

Windows version compiles and runs fine now with this PR, on OSX it's still not picking up the working directory. Since I also have this problem with the turbobadger demo I suspect I broke something in fips on OSX. I'll have a look at it in the evening. Thanks for the fix!

[floooh]

Ok, so the 'current working dir' problem on OSX has to do with the samples being compiled as fips cmdline apps instead of 'windowed' app (which produces a mac .app bundle). For some reason starting such an executable ignores the current directory, it doesn't even work running directly from the shell inside the fips-bgfx/bgfx/examples/runtime directory. You'll have to copy the executable to this directory in order to make it work.

This is most likely also the reason why the turbobadger demo doesn't work on OSX>

I'll see if I can find out more...

[floooh]

Ok found the problem, at least for the fips-bgfx demos:

entry_osx.mm has code which changes the working directory:

https://github.com/bkaradzic/bgfx/blob/master/examples/common/entry/entry_osx.mm#L66

If compiled as command line executable, 'path' points to the directory where the executable lives, and thus overrides the current working directory where the program was started from which causes the startup error when building as fips-bgfx demo.

Now the curious case why it works as OSX app bundle: in this case the path is resolved to a directory inside the bundle directory e.g. /Users/floh/...../01-cubes.app/Contents/Resources
BUT the Resources subdirectory doesn't exist, thus the chdir() call fails, and the current working directory remains set which when started as fips-bgfx demo, points to bgfx/examples/runtime.

@bkaradzic: what do you think about a new C preprocessor define which prevents this chdir() when set, but defaults to the current behaviour?

[floooh]

PS: turbobadger has a similar problem, to workaround a (non-existing) problem in GLFW, and also only on OSX. GLFW can be compiled to set the current working directory to the applications Resources directory here:

https://github.com/glfw/glfw/blob/1634742177eded4b8412d7ab11494ed662d20905/src/cocoa_init.m#L203

...and the turbobadger demo has this line which tries to undo this in a rather naive (or rather, 'hacky') way:

https://github.com/fungos/turbobadger/blob/master/Demo/platform/port_glfw.cpp#L453

@fungos since you have forked turbobadger anyway, I would propose to add a new define which controls this behaviour, and default to the current behaviour of calling chdir()?

[floooh]

PS: @bkaradzic the spammy compiler output is because of xcodebuild which is the default config on OSX. If you use 'fips set config osx-make-release' or 'fips set config osx-ninja-release', the output is more commandline-friendly :)

[fungos]

Ouch, good find. Yes, I will patch this tomorrow on my fork and try to push mainline too as I've already done something similar for linux.

UPDATE: Probably fixed fungos/fips-turbobadger@043b8c5 and https://github.com/fungos/turbobadger/commit/adb6601155b97b04807afb55c2cb0ec4bbd264c2

[floooh]

The second commit had a small problem (#ifdef instead of #if used), I provided a PR which fixes this, with this fix the turbobadger demo works fine on OSX: https://github.com/fungos/turbobadger/pull/1

[fungos]

I think you can close this too. :)

[floooh]

Okidoki