search

floooh / fips-bgfx

fipsified version of bgfx (https://github.com/bkaradzic/bgfx)
17 stars 8 forks source link

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

Closed floooh closed 8 years ago

floooh commented 9 years ago

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 commented 9 years ago

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

bkaradzic commented 9 years ago

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 commented 9 years ago

For the compiler error on windows I've added the missing define here https://github.com/floooh/fips-bgfx/pull/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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/fungos/fips-turbobadger/commit/043b8c56f06d4476be90c80592e3ceedf93e9bf3 and https://github.com/fungos/turbobadger/commit/adb6601155b97b04807afb55c2cb0ec4bbd264c2

floooh commented 9 years ago

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 commented 8 years ago

I think you can close this too. :)

floooh commented 8 years ago

Okidoki