In this case your bundle should go into root cmakelists - this is not bundle for client but for vcmi itself.
Anything global to vcmi should go into root cmakelists.
Anything specific to project should be in project cmakelists.
Of course I could make an empty bundle for vcmiclient target and copy everything else to it in package step. But is very very inconvinient. When I’ll start vcmiclient bundle from Xcode for debugging it will look for all resources, server executable and AI libs inside bundle. I can’t specify DATA_DIR to /Users/stopiccot/h3 while debugging executable and return to ./…/Data (relative path inside bundle) in runtime. So from some theoretical point of view it is more logical to do all copying at package step. But in real life you will end up copying files to their locations inside bundle by hand if you want to debug something. This will ruin all developing experience on OS X. Is cmake script prettiness worth of it?
Regarding CMAKE_INSTALL_RPATH it simply does not work for me. Because what I need is to get such thing in Xcode project - grab.by/hws0 so library install names containing @rpah (@rpah/SDL.framework/Versions/A/SDL) will expand correclty (@executable_path/…/Frameworks/SDL.framework/Versions/A/SDL).
Anything wrong with using server\libs from bundle?
Theoretically you can place all H3 data in ~/.vcmi directory instead of DATA_DIR and keep bundle as it - no need to manually move files.
In this case I agree.
But I think that you should check Mac-specfic generators in CPack - they can correctly copy files from cmake INSTALL command instead of manual cp’s
How I should distinguish developer case and look for game data in ~/.vcmi and look inside bundle for end-user? I see the only options to introduce something like PATH for DATA_DIR so it could be defined as: “…/Data:~/.vcmi”
VCMI always checks for both locations: data dir and user dir.
You may split data between these directories in any way you want. For example config and Mods directories can be copied from source to bundle during packaging and users will place all H3 data in ~/.vcmi (useful on Linux where DATA_DIR is owned by root)
Check config/filesystem.json to see where VCMI looks for resources
Check lib/Filesystem/CResourceLoader.cpp (method CResourceHandler::initialize ) to see code
I’ve looked through CResourceLoader.cpp but still do not understand why instead of ability to define multiple folders for DATA_DIR constant we have this hardcode with userdir. Defining DATA_DIR to “…/Data:~/.vcmi” would be a much more robust solution and BIN_DIR could leverage from this too. Defining BIN_DIR to “.:…/…/…/” would be enought to eliminate copy step in vcmiclient target for OS X.
All that *_DIR constants are coming from ancient code. VCMI definitely needs some way to specify them on startup.
Some enviroment vars like VCMI_DATA_DIR should be trivial to implement. Console arguments should work too but they should be passed to server manually on game start.
Multiple entries for data and lib dirs are fine but I think that user drectory should remain separate from data.
Binary dir can be replaced with path to server so its use will be more clear
One more problem on OS X is video playback. Currently i’m gettings this grab.by/hKcM. Seems to be BGR instead of RGB. Any ideas what could have triggered it? Maybe ffmpeg needs to be compiled with some specific flags or something eles? Any clues? Maybe somebody already had such errors and could save my time?
By the way… How is that includes are platform specific? I see CBattleAnimations.h included in CBattleInterface.h — why is it needed?
I’m not sure if it belongs there, it is r3019, not the actual VCMI 0.9. Besides, I’m not sure how to label it or whether it needs some additional instructions.
How about creating a wiki page “Installation on OS X” with download link and instructions just like we have wiki.vcmi.eu/index.php?title=Ins … n_on_Linux ? [Or, if there’s little difference, we could make it a single page for both Linux/OS X.]
You can edit vcmi wiki after signing in with your forum account.
To tell the truth I don’t know myself Maybe it’s a sign of Clang immaturity. Maybe something else. But in some places forward declarations haven’t worked so I replaced them with direct includes.
I’ve already have draft “Building VCMI on OS X” but I’m waiting for my new SSD to arrive soon. I’m going to install fresh system on it anyway so it would be a great possibility to check everything one more time on a clean system.
What about end-user installing it’s really dead simple. Every OS X user will do it. The only problem is game data which anyway should be obtained separately and placed to “~/.vcmi”. I’m a bit concerned about it because for myself I installed Heroes3 + WoG on Windows machine, compressed to zip archive and copied to Mac. Not sure it’s a good solution because some people don’t have second computer with Windows. We have the same problem on Linux so maybe we need shared “Preparing game data on non-Windows system” page. Any ideas? Because Wine based manual is not very best solution from my point of view.
Strange thing is that I use clang as well. And I don’t need those includes.
The only difference I can think of is standard library (libstdc++ for me, libc++ on Mac) but it shouldn’t affect includes either.
Will commit the script to svn today so you can check how it works on Mac. Shouldn’t be a problem - it requires bash itself + some optional utilites to extract data (wget, unzip, unshield, innoextract).
Yep, I’m using libc++ because libstdc++ on OS X is way outdated (from gcc 4.2). And I can’t use libstdc++ from newer gcc installed from MacPorts because of portability.
Yeah, unshield install seems to be working fine after some patches to unshield itself. Can anyone provide me iso with InnoSetup install to test innoextract?