Today I've been working on better support for the Visual Studio project files. And I have come across a major problem, that has yet been ignored:
The files in bin/
As far as Oli told me, this is an issue in linux anyway. But I neither can nor do care about the problem under linux. I'll let the Adi or Oli handle this issue.
Anyway, the problem still exists under Windows: Even if you still have all your config files in bin, you cannot build debug and release at the same time. For now, I have dealt with it by postfixing "_d" to every file. But that's not exactly a very good solution. So I've decided to make folders for every msvc solution (I'm starting to port things to VS08) and every configuration (only debug and release).
And of course I want to make this Orxonox SDK easily distributable, so I have to deliver the plugins.cfg from ogre and I also need to set the dataPath differently than the default value (hard coded).
In order to solve this by not adding four more files to bin/ (name plugins.cfg-init2_d or something even worse), I took the liberty of creating a new root directory in the trunk: "init"
It contains a folder named "common" where all those files lie, that are needed by Orxonox to run and are platform independent (they also need to be exactly in the same folder as the executable). There is another folder, "orxonox_vc8", with two subfolders, "debug" and "release", which contain plugins.cfg and orxonox.ini (specifically designed that the Visual Studio SDK works in the first place).
Now whenever the build process is complete, these files are all copied to the output directory (for instance bin/orxonox_vc8/release) if not yet existing.
I honestly have very little idea how that is handled under linux (make install?), so however this is dealt with, I am willing to adapt to it as long as I can apply the scheme described above in some way (for visual studio of course).
Furthermore I talked to Oli and he wasn't too pleased about the name "init". "config" was his suggestion. As I said I'm open for suggestions and I don't really care how it is solved as long as the Visual Studio stuff can be made to work properly like now.
The changes with the folders were applied to the trunk, so Adi, If this is part of your upcoming work, I suggest to merge back the buildsystem branch as soon as one more linux user, fabian (mingw) and me have tested it. But it's only a suggestion. Again, I don't feel too well informed to judge the issue like that...
EDIT: Perhaps something I would like to add:
We are currently quite creative when it comes to distributing plugins.cfg:
- On standard linux, the run-script copies plugins.cfg-init to plugins.cfg
On Windows with MinGW, we simply use Plugins.cfg
On an eth tardis box, again, the run-script copies plugins.cfg-init, but also edits the PluginsFolder.
On Windows with Visual Studio, contents from the init folder are copied to the output directory, including plugins.cfg.
Btw: There is an SVN patch on my box that would effectively remove plugins.cfg and put its contents to orxonox.ini, if that is desired. --> One config file less, but plugins.cfg would probably be easier to configure by CMake.