Up-to-date FreeOrion Mac-SDK and build - Test please!
Moderator: Oberlus
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
Yeah we should split up the libs into more "digestible" parts. I am not sure wether or not to remove the ZERO_LINK flag but the GCC_MODEL_TUNING flag should be safe to remove since we do not support PowerPC anymore.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
Should it still run on OSX 10.6 ?night wrote:OS: Mac OS X Lion 10.7.2 (11C74)
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
Poor 10.6 user votes fervently in favor of FO being able to run on 10.6!Geoff the Medio wrote:Should it still run on OSX 10.6 ?
Seriously: why not? If it weren't so much trouble to get it done, I'd even suggest to try to build FO for 10.5+ ...
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
Yes it does run on 10.6. 10.7.2 is only my OS version.
Vezzra you could make it run on 10.5 if you compile it with the 10.5 Base SDK. I am not able to do it because I have Xcode 4 installed.
Vezzra you could make it run on 10.5 if you compile it with the 10.5 Base SDK. I am not able to do it because I have Xcode 4 installed.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
Could you elaborate on that? I thought tzlaine fixed the 1.48 issues, at least on Linux...night wrote:The build was based on rev. 4541 with Boost 1.47.0 (1.48.0 still does not work with GG).
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
Ok, I'll give it a try. I just thought I read something about a lot of build errors when trying to build FO for 10.5.night wrote:Vezzra you could make it run on 10.5 if you compile it with the 10.5 Base SDK. I am not able to do it because I have Xcode 4 installed.
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
Hi night,
I've spent the last two days tinkering with build settings, build configurations, test building and playtesting, and managed to clean up a bit (hopefully).
1.) During my tinkering and repeatedly building FO I had issues with the build process again. So I finally decided to split up the parser cpp's completely and made one build target for almost every single cpp file. That took care of these issues so far, and also sped up the build process a bit. The downside of course is having more than 30 build targets now, that's a bit cumbersome.
2.) I moved settings that were the same for each build target into the project build settings and reset these settings on the individual build target level. Also cleaned up the search path settings for frameworks, headers and libraries. There were some pointing to directories that didn't exist anymore, several that were redundant, etc. There are also several settings I left unchanged because I don't know what they do and why they have been set to their current values.
3.) I made new "Release" build configurations where debug symbol generation is turned off, all symbols get stripped from the final executeables and the optimization level is set to "smallest, fastest". For the "Debug" build configuration I enabled debug symbol generation (of course), set level of debug symbols to "all symbols" and optimization level to "none". I didn't delete the old "ReleaseUniversal" build configuration, I just renamed it to "ReleaseUniversal-OLD", so we can peek into it if needs be.
4.) There are several user defined settings, especially in the FreeOrion app bundle build target, which I can't figure out. I don't know why they are there and what they do, so I left them (I tried to remove some of them, but that resulted in build issues again, so I discarded these changes).
6.) Finally I also tried to build FO for OS X 10.5. With this I haven't been as lucky, see this thread.
I've zipped my FreeOrion.xcodeproj package and attached it to this post, so you can examine my modifications for yourself. If you think it's ok then I'd suggest to update the OSX SDK with this modifications.
I've spent the last two days tinkering with build settings, build configurations, test building and playtesting, and managed to clean up a bit (hopefully).
1.) During my tinkering and repeatedly building FO I had issues with the build process again. So I finally decided to split up the parser cpp's completely and made one build target for almost every single cpp file. That took care of these issues so far, and also sped up the build process a bit. The downside of course is having more than 30 build targets now, that's a bit cumbersome.
2.) I moved settings that were the same for each build target into the project build settings and reset these settings on the individual build target level. Also cleaned up the search path settings for frameworks, headers and libraries. There were some pointing to directories that didn't exist anymore, several that were redundant, etc. There are also several settings I left unchanged because I don't know what they do and why they have been set to their current values.
3.) I made new "Release" build configurations where debug symbol generation is turned off, all symbols get stripped from the final executeables and the optimization level is set to "smallest, fastest". For the "Debug" build configuration I enabled debug symbol generation (of course), set level of debug symbols to "all symbols" and optimization level to "none". I didn't delete the old "ReleaseUniversal" build configuration, I just renamed it to "ReleaseUniversal-OLD", so we can peek into it if needs be.
4.) There are several user defined settings, especially in the FreeOrion app bundle build target, which I can't figure out. I don't know why they are there and what they do, so I left them (I tried to remove some of them, but that resulted in build issues again, so I discarded these changes).
5.) Well, I didn't know why you wanted to try this, as I have no idea what this LLVM compiler is. But I thought I'd try that too, and created a "Release" build configuration with the compiler version set to "LLVM GCC 4.2". I didn't find a setting with LLVM 3.0, but that's maybe because I'm working with Xcode 3. Anyway, this worked flawlessly, and the results are encouraging: I got the impression that the build process runs a bit smoother and even more reliable (with GCC 4.2 I got "segmentation faults" several times which could be solved by just repeating the build, with LLVM GCC 4.2 however I haven't this kind of problem yet). The resulting executeables are significantly smaller than when compiling with GCC 4.2: freeoriond with GCC 4.2 -> 53.1MB, with LLVM GCC 4.2 -> 29.6MB. The ratio for the other two executeables is similar.night wrote:Also it would be nice if the FO source code would work with Apple's new LLVM 3.0 compiler (currently it fails cause of the Adam and Eve libs from Adobe in GG).
6.) Finally I also tried to build FO for OS X 10.5. With this I haven't been as lucky, see this thread.
I've zipped my FreeOrion.xcodeproj package and attached it to this post, so you can examine my modifications for yourself. If you think it's ok then I'd suggest to update the OSX SDK with this modifications.
- Attachments
-
- FreeOrion.xcodeproj.zip
- FreeOrion Xcode project package
- (158.01 KiB) Downloaded 101 times
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
Hello Vezzra,
Thank you for the great amount of effort you put into restructuring the project. The 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!
LLVM GCC 4.2 is the default compiler in Xcode 4. GCC 4.2 is not even installed. With Xcode 4 you also get the Apple LLVM compiler 3.0. You can read about the advantages and disadvantages of the different compilers here.
I just thought back then that the project would be more future-proof if it was able to compile on the new LLVM 3.0 compiler. Still LLVM GCC 4.2 seems to be the best solution for our purposes since it combines both compatibility and the new features of the LLVM system. As you're getting better results with LLVM GCC 4.2 I suggest we make that the default compiler for our build configurations.
For my attempt to make a new SDK I modified the project a bit:
- Removed the libboost_date_time.a from the project (does to seem to be needed)
- Set LLVM GCC 4.2 as the default compiler for all configurations except the Release_LLVM target where it is Apple LLVM compiler 3.0
- Removed ConditionParser from the dependency list of target dependencies of GG
- Set the build configurations of 'Build for archiving' and 'Build for profiling' to 'Release'
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
Here's the link to the SDK
The modified project is attached to this post.
night
Thank you for the great amount of effort you put into restructuring the project. The 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!
LLVM GCC 4.2 is the default compiler in Xcode 4. GCC 4.2 is not even installed. With Xcode 4 you also get the Apple LLVM compiler 3.0. You can read about the advantages and disadvantages of the different compilers here.
I just thought back then that the project would be more future-proof if it was able to compile on the new LLVM 3.0 compiler. Still LLVM GCC 4.2 seems to be the best solution for our purposes since it combines both compatibility and the new features of the LLVM system. As you're getting better results with LLVM GCC 4.2 I suggest we make that the default compiler for our build configurations.
For my attempt to make a new SDK I modified the project a bit:
- Removed the libboost_date_time.a from the project (does to seem to be needed)
- Set LLVM GCC 4.2 as the default compiler for all configurations except the Release_LLVM target where it is Apple LLVM compiler 3.0
- Removed ConditionParser from the dependency list of target dependencies of GG
- Set the build configurations of 'Build for archiving' and 'Build for profiling' to 'Release'
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
Here's the link to the SDK
The modified project is attached to this post.
night
- Attachments
-
- FreeOrion.xcodeproj.zip
- (198.37 KiB) Downloaded 113 times
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
Would that be appropriately labeled FreeOrion_Mac_OS_X_SDK_Intel_32-Bit_Xcode4_31_Dec_2011.tar.gz ?night wrote:Here's the link to the SDK
Does anything other than the updated project.pbxproj need to be committed to SVN?The modified project is attached to this post.
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
Yes.Geoff the Medio wrote:Would that be appropriately labeled FreeOrion_Mac_OS_X_SDK_Intel_32-Bit_Xcode4_31_Dec_2011.tar.gz ?
It would be nice if the Version.cpp and Info.plist would be updated too.Geoff the Medio wrote:Does anything other than the updated project.pbxproj need to be committed to SVN?
Here's the latest info.plist
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
Hm, may I suggest a small modification? I would replace the part with "_Xcode4_" by "_Xcode3_", since the project format for the Xcode project package contained in the SDK is set to "Xcode 3.2-compatible", so it's actually a Xcode3 project. The file name of the SDK should reflect that to avoid confusion, shouldn't it?night wrote:Yes.Geoff the Medio wrote:Would that be appropriately labeled FreeOrion_Mac_OS_X_SDK_Intel_32-Bit_Xcode4_31_Dec_2011.tar.gz ?
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
I did not know that. Your name should be more suitable.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
Someone posted a bug about the research screen crashing the OSX latest SVN build: https://sourceforge.net/tracker/?func=d ... tid=544942
I haven't seen this on Windows.
I haven't seen this on Windows.
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
I can't reproduce this crash. We will have to wait for logs/saves.
Re: Up-to-date FreeOrion Mac-SDK and build - Test please!
Ditto here. Couldn't reproduce the crash, tried it on two different Macs. However, all my machines run 10.6.8, not Lion.night wrote:I can't reproduce this crash. We will have to wait for logs/saves.