You're welcome I think it's an effort well spent because now I just can hit CMD-B to build the project. Before I had to manually compile EffectsParser.cpp, then the parser cpp's, then the rest of the project each time one or more parts of the parser had to be recompiled (due to whatever changes). Doing that several times over took more time then the restructuring of the project to get rid of this annoying problemnight wrote:...Thank you for the great amount of effort you put into restructuring the project.
Thanks! I'm glad this turned out so wellThe new organization might have lots of targets but uses less RAM during the compilation. Having the smaller targets does not impact the building speed on my system at all and the new release configuration creates a smaller way faster binary (1,49 GB to 468 MB). Great job!
Excellent idea. I absolutely agree....As you're getting better results with LLVM GCC 4.2 I suggest we make that the default compiler for our build configurations.
All your other modifications to the project make sense too, to me at least, they seem to be sound.
I think that's also an excellent idea. I don't know if old .svn folders are likely to cause problems if they are too far outdated, but IMO your new solution is the safer way to do things anyway. I've already tested this new SDK, first on my main development machine (in a test folder), then on another Mac where I hadn't anything FO related installed, both test went smoothly, so all your modifications seem to work well. I'd say we stick with the new approach.The 'old' approach was having a .svn folder inside the archive of the SDK. The user had to run 'svn update' to get the latest sources as well as the remaining content. I'm afraid that this solution could cause some problems in the future. Old .svn folders from another system as a foundation for a fresh development environment do not seem to be the best idea.
The new SDK is cleaner and easier to set up than the old one. You just download the archive, unzip it and run the bootstrap.command file. The script then downloads the latest sources from SVN and adds the contests of the SDK to it. In the end the user has a clean, new copy of the subversion repo on his/her system.
The new approach is just a suggestion of mine, we can still stick to the other way if I have overlooked some major flaw
One remark concerning version.cpp: I suggest to keep the version string format consistent across platforms. On windows it's "v0.3.17+ [SVN 4549] MSCV 2010". I'd follow this pattern, so instead of "post-v0.3.17" stick with "v0.3.17+", omit the "GitMirror" part (as that relates to your specific setup), omit the "r" in front of the SVN revision number and use "Xcode3" as reference for the build environment: "v0.3.17+ [SVN 4549] Xcode3". Only if you want to provide a build that has additional patches applied (that haven't been committed to SVN) I'd suggest to append some kind of suffix to the SVN revision number to indicate that this isn't a build based solely on SVN (like "+p" or something like that).
That was nice teamwork!