Header search path problem when using turbobadger module in standalone project

[mgerhardy]

Did a small test by putting the turbo badger ui sample into a dedicated project. But activating unittests and building (even without unittests) fails. Maybe I'm doing something silly wrong. Here is the sample: http://88.198.107.20/testimport.tar.gz

Help would be cool.

[floooh]

There's a standalone app here, but this hasn't been updated in a while for the Gfx module API changes. I'll try to get this uptodate this evening.

https://github.com/floooh/oryol-test-app

[floooh]

I have updated the oryol-test-app project so that it works again, and currently have a quick look at your archive.

[floooh]

PS: I actually had strange cmake error messages that the C/C++ compiler doesn't work which were caused by an old build directory I had lying around. I had to do a './fips clean' to get rid of this.

[floooh]

Your demo actually compiles fine on OSX apart from one error: /Users/floh/fips-scratch/testimport/src/TBDemoWindows.cc:197:19: No member named 'ShowDebugInfoSettingsWindow' in 'tb::MainWindow'

I started from scratch like described in the standalone app:

> mkdir fips-scratch
> cd fips-scratch
> ...copy testimport directory to fips-scratch...
> cd testimport
> ./fips fetch
> ./fips gen
> ./fips open
...continue in Xcode

When starting the demo, it takes quite a bit of time to download all the small resource files, but this also happens in the 'integrated' turbobadger demo. It's better to change the ORYOL_SAMPLE_URL cmake option to 'http://localhost:8000/' (using ./fips config, don't forget the trailing slash), and start a local webserver under ~/oryol/data with 'python -m SimpleHTTPServer'. And after removing the call to ShowDebugInfoSettingsWindow, voila :)

[floooh]

PS: just committed some small fixes for D3D11 on Windows to the oryol-test-app repository.

[mgerhardy]

Thanks a lot. I remember some problems with libcurl when compiling my test project under linux x86_64, Will check it out again and report the exact error asap.

[mgerhardy]

after removing the debug window I get e.g. this:

Linking CXX executable /home/mgerhardy/dev/fips-deploy/testimport/linux-make-debug/testimport
../fips-turbobadger_turbobadger/libturbobadger.a(tb_system_linux.cpp.o): In Funktion `tb::TBSystem::GetTimeMS()':
/home/mgerhardy/dev/fips-turbobadger/turbobadger/src/tb/tb_system_linux.cpp:27: Mehrfachdefinition von `tb::TBSystem::GetTimeMS()'
../oryol_TBUI/libTBUI.a(tbOryolSystem.cc.o):/home/mgerhardy/dev/oryol/code/Modules/TBUI/tb/tbOryolSystem.cc:12: first defined here
../fips-turbobadger_turbobadger/libturbobadger.a(tb_system_linux.cpp.o): In Funktion `tb::TBSystem::GetLongClickDelayMS()':
/home/mgerhardy/dev/fips-turbobadger/turbobadger/src/tb/tb_system_linux.cpp:40: Mehrfachdefinition von `tb::TBSystem::GetLongClickDelayMS()'
../oryol_TBUI/libTBUI.a(tbOryolSystem.cc.o):/home/mgerhardy/dev/oryol/code/Modules/TBUI/tb/tbOryolSystem.cc:24: first defined here
../fips-turbobadger_turbobadger/libturbobadger.a(tb_system_linux.cpp.o): In Funktion `tb::TBSystem::GetPanThreshold()':
/home/mgerhardy/dev/fips-turbobadger/turbobadger/src/tb/tb_system_linux.cpp:45: Mehrfachdefinition von `tb::TBSystem::GetPanThreshold()'
../oryol_TBUI/libTBUI.a(tbOryolSystem.cc.o):/home/mgerhardy/dev/oryol/code/Modules/TBUI/tb/tbOryolSystem.cc:30: first defined here
../fips-turbobadger_turbobadger/libturbobadger.a(tb_system_linux.cpp.o): In Funktion `tb::TBSystem::GetDPI()':
/home/mgerhardy/dev/fips-turbobadger/turbobadger/src/tb/tb_system_linux.cpp:55: Mehrfachdefinition von `tb::TBSystem::GetDPI()'
../oryol_TBUI/libTBUI.a(tbOryolSystem.cc.o):/home/mgerhardy/dev/oryol/code/Modules/TBUI/tb/tbOryolSystem.cc:42: first defined here
../fips-turbobadger_turbobadger/libturbobadger.a(tb_system_linux.cpp.o): In Funktion `tb::TBSystem::GetPixelsPerLine()':
/home/mgerhardy/dev/fips-turbobadger/turbobadger/src/tb/tb_system_linux.cpp:50: Mehrfachdefinition von `tb::TBSystem::GetPixelsPerLine()'
../oryol_TBUI/libTBUI.a(tbOryolSystem.cc.o):/home/mgerhardy/dev/oryol/code/Modules/TBUI/tb/tbOryolSystem.cc:36: first defined here
collect2: error: ld returned 1 exit status
src/CMakeFiles/testimport.dir/build.make:155: recipe for target '/home/mgerhardy/dev/fips-deploy/testimport/linux-make-debug/testimport' failed
make[2]: *** [/home/mgerhardy/dev/fips-deploy/testimport/linux-make-debug/testimport] Error 1
CMakeFiles/Makefile2:1297: recipe for target 'src/CMakeFiles/testimport.dir/all' failed
make[1]: *** [src/CMakeFiles/testimport.dir/all] Error 2
Makefile:75: recipe for target 'all' failed
make: *** [all] Error 2
[ERROR] Failed to build config 'linux-make-debug' of project 'testimport'

Will try to fix it. Looks like this is a linux specific turbobadger issue. But there were some issues with libcurl - will come back to it once I am at those errors again ;)

[mgerhardy]

ah the include paths are wrong the turbobadger tb_config.h is used instead of the one that comes with oryol.

In this particular case TB_SYSTEM_LINUX is defined. But I'm not sure why it works on osx...?

[mgerhardy]

any idea how to change the include path order to put the fips-turbobadger include paths after the code/Modules/TBUI/tb include path?

[floooh]

hmm that's strange, the fips-include.cmake file in oryol has the search path set, and this should also be included in standalone projects... buuuuut, this has a local path set (code/Modules/TBUI/tb), may be this is now relative to the standalone project (which is very likely)...

You could try this: change it to 'include_directories(${FIPS_PROJECT_DIR}/../oryol/code/Modules/TBUI/tb)'. If this works I'll change it directly in oryol

I haven't tested TBUI standalone projects yet, that's why I did not stumble over the problem yet...

[mgerhardy]

unfortunately that didn't help, the fips-turbobadger include dir is still in front of the oryol tb dir.

[floooh]

Hmm ok, dirty hack: try putting an include_directory to the oryol-directory which contains the tb_config.h file under TBUI/tb into your root CMakeLists.txt file before the fips_setup() call. You can use get_filename_component(ORYOL_ROOT_DIR "../oryol" ABSOLUTE) to avoid putting an absolute path into your CMakeLists.txt file...

I'll keep this bug open because I think we need to find a better solution (but I can't think of one at the moment).