[solved] OIS::MultiTouch has not been declared

[d000hg]

I'm getting tons of compile errors, all seemingly related to IOS, building Ogre 1.8 for iOS on XCode 3.2.6. Starting with:

/usr/local/ogre/ogre1.8/src/Samples/Common/include/Sample.h:144: error: 'OIS::MultiTouch' has not been declared

I have the iOS 4.3 pre-built dependencies and it seems everything else like OgreMain is building fine. Perhaps those older prebuilt dependencies use an older IOS version, is this feasible?

[masterfalcon]

It should work. Could you give more information on how you've configured with cmake and how you are building? And some more of the log. Thanks

[d000hg]

I found the answer to that issue - I have both a /Dependencies and /iOSDependencies in my main ogre dir, since I'm building to separate build dirs for iOS and Mac, and CMake was defaulting to /Dependencies. Setting it explicitly removed the OIS errors though some linker errors remain - these are the only 20 errors I get doing ALL_BUILD and all are from linking SampleBrowser:

"_Get1IndResource", referenced from:
"_FSOpenResourceFile", referenced from:
"_GetResource", referenced from:
"_FSPathMakeRef", referenced from:
"_GetResInfo", referenced from:
"_Get1Resource", referenced from:
"_GetHandleSize", referenced from:
"_FSGetForkCBInfo", referenced from:
"_ATSFontFindFromName", referenced from:
"_FSGetCatalogInfo", referenced from:
"_CloseResFile", referenced from:
"_ReleaseResource", referenced from:
"_FSCompareFSRefs", referenced from:
"_FSpMakeFSRef", referenced from:
"_FSRefMakePath", referenced from:
"_ATSFontGetFileSpecification", referenced from:
"_HomeResFile", referenced from:
"_FSOpenResFile", referenced from:
"_ResError", referenced from:
"_UseResFile", referenced from:

My CMake settings are the default other than changing the dependencies dir. I'm using the CMake GUI, let me know if there are particular vars I should post. The only thing I was wondering about from casual browsing is threading/boost, which seems to be on by default while I don't have boost.

[masterfalcon]

Well, those are all Carbon methods so something went wrong with CMake. Erase CMakeCache.txt from your build directory, fire up CMake, only enable OGRE_BUILD_PLATFORM_APPLE_IOS before you configure. Then you should be good to go.

[d000hg]

I've cleared my build dir and started afresh, the only things I've changed from the defaults are:

- set the dependency dir explicitly
- checked iOS platform option
- unchecked OpenGL and checked GL ES & ES2 boxes

I am wondering if the script is buggy though because despite setting my iOSDependencies dir, I see this when I run the configuration:

Search path: /usr/local/ogre/ogre1.8/iOSDependencies;/usr/local/ogre/ogre1.8/build/ios/iOSDependencies;/usr/local/ogre/ogre1.8/src/iOSDependencies;/usr/local/ogre/ogre1.8/build/ios/../iOSDependencies;/usr/local/ogre/ogre1.8/src/../iOSDependencies
Looking for ZLIB...
Found ZLIB: optimized;/usr/lib/libz.dylib;debug;/usr/lib/libz.dylib
Looking for ZZip...
Found ZZip: optimized;/usr/local/ogre/ogre1.8/Dependencies/lib/release/libzzip.a;debug;/usr/local/ogre/ogre1.8/Dependencies/lib/debug/libzzip.a
Looking for FreeImage...
Found FreeImage: optimized;/usr/local/ogre/ogre1.8/Dependencies/lib/release/libfreeimage.a;debug;/usr/local/ogre/ogre1.8/Dependencies/lib/debug/libfreeimage.a
Looking for FREETYPE...
CMAKE_PREFIX_PATH: /usr/local/ogre/ogre1.8/iOSDependencies;/usr/local/ogre/ogre1.8/build/ios/iOSDependencies;/usr/local/ogre/ogre1.8/src/iOSDependencies;/usr/local/ogre/ogre1.8/build/ios/../iOSDependencies;/usr/local/ogre/ogre1.8/src/../iOSDependencies;/usr/local;/usr/lib/i386-linux-gnu

In other words it seems to use my iOS folder for somethings and the other one for others.

Maybe I'm using it wrong, but shouldn't I be fine having one Ogre source folder with separate Dependencies and iOSDependencies folders for building Ogre on Mac/iOS?

[masterfalcon]

Let's try again. This time, as I'd suggested, ONLY set the iOS platform option. It will pick up the render systems and dependencies automatically. Also, it appears that you have multiple copies of the iOS Dependencies, you only need to have them in the root directory.

[d000hg]

Ah, I didn't realise it would do the render-systems automatically.

However I don't have 2 copies of the iOS dependencies, what I've got is:

-ogre1.8
--src
--build
---iOS
---mac
-Dependencies
-iOSDependencies

When I clean up my build-dir and start again, CMake is detecting ogre1.8/Dependencies and using that, which lead to the problems at the start of the thread, as that is the Mac version of the dependencies. checking the iOS-platform box only in a brand new clean build and re-configuring, leads to similar output as my last post - some dependencies automatically find the iOSDependencies dir, others still use the Dependencies dir. Making me think setting up for both Mac and iOS builds of Ogre is problematic.

Here is a PasteBin of the CMakeCache.txt when I created a brand new build-dir, and followed your instructions to the letter this time (tick iOS platform, reconfigure, generate): http://pastebin.com/ZXvV0Qvt

[masterfalcon]

It could be that your build dir is two levels deep. On my machine I have build(which I use for iOS) and buildosx instead of build/ios and build/osx.

[d000hg]

Worth a try
What does your overall dir-structure look like in terms of how the Ogre source, and the Mac/ioS dependencies dirs, are setup?

I think next (if that doesn't help) I will find-replace /Dependencies with /iOSDependencies in the saved script file, however those linker errors concern me. And XCode is so damn slow to build that every new attempt is 30min until it gets that far

Will report back - thanks for the help.

[masterfalcon]

My directory structure, besides everything in the repo is like this:

build
buildosx
Dependencies
iOSDependencies

[d000hg]

Are those inside your Ogre source dir, or higher up in a parent/separate path? Anyway I'll try separate build dirs next...

[masterfalcon]

At the root level of the source dir.

[d000hg]

Well, I couldn't stop it picking up my /Dependencies automatically for some libs. But a search/replace in the .txt file led to a successful build (well very nearly successful, that's another post).

I don't know why I had this issue and MF didn't, but it was a fairly easy fix.