Thanks for your report totya. It is fixed in r4960. Although nightlies are expected to contain bugs etc., such reports of build failures are welcome. The source tree should never be in a non-compiling state.

There are some dependencies in 'dep' folder. I want to rebuild them too, with modern core and SSE2 suport. Especially the JavaScript engine, the JS32ECMAv5.dll.

Where can I find the sources for this one, and how to build it?

The bad news is that you are setting up yourself for a lot of work if you want to build all the dependencies from scratch. The good news is that it can be done though. Be aware that most of the Win32 dependencies require modifications specifically for supporting Oolite anyway. The modified SDL.dll sources are already included in the trunk's cross platform deps folder and the modifications required for libespeak.dll are also included. For the rest, you will have to get the sources yourself and make sure you download the versions used in Oolite, because there are no guarantees whatsoever that newer library versions will work.

Be sure to read the document titled ExternalLibrariesSourceCodeChanges.txt, located in the Doc folder before you begin. Start with the basics: zlib1.dll, SDL.dll, libogg/libvorbis + SDL_mixer.dll, libpng14.dll. I know that there will be lots of questions, so feel free to take it to PM if you get stuck. I will try to help as much as I can.

Regarding the js32ECMAv5.dll, this is the source of the Spidermonkey library for Firefox 4. Building this is a b!tch of a task. I will probably have to send you ready-made makefiles for it, because the official Spidermonkey build does not support our toolchain (GCC/MinGW) and yet another special build had to be made for it.

Another one of the bad ones is gnustep-base-1_20.dll, but leave that till very last. It has extensive modifications to the Objective-C library itself.

The bad news is that you are setting up yourself for a lot of work if you want to build all the dependencies from scratch. The good news is that it can be done though. Be aware that most of the Win32 dependencies require modifications specifically for supporting Oolite anyway. The modified SDL.dll sources are already included in the trunk's cross platform deps folder and the modifications required for libespeak.dll are also included. For the rest, you will have to get the sources yourself and make sure you download the versions used in Oolite, because there are no guarantees whatsoever that newer library versions will work.

Be sure to read the document titled ExternalLibrariesSourceCodeChanges.txt, located in the Doc folder before you begin. Start with the basics: zlib1.dll, SDL.dll, libogg/libvorbis + SDL_mixer.dll, libpng14.dll. I know that there will be lots of questions, so feel free to take it to PM if you get stuck. I will try to help as much as I can.

Thank you. I'll start with SDL, then. However (in my opininon) this library is not critical in terms of game performance. I think the maximum performance gain can be achieved by rebuilding the JS engine and Objective-C library. Maybe PNG library, too.

Quote:

Regarding the js32ECMA5.dll, this is the source of the Spidermonkey library for Firefox 4. Building this is a b!tch of a task. I will probably have to send you ready-made makefiles for it, because the official Spidermonkey build does not support our toolchain (GCC/MinGW) and yet another special build had to be made for it.

Another one of the bad ones is gnustep-base-1_20.dll, but leave that till very last. It has extensive modifications to the Objective-C library itself.

There is an update to the build system for Oolite on Windows. As of today, we are switching the compiler to GCC 4.7.1, as opposed to the 4.3.2 one we were using until now. This will enable us to make use of quite a few new ObjC language features and at the same time reap the benefits of the performance optimizations done on the compiler since about 2009. Anyone building Oolite from source on Windows should upgrade to the new development environment, found here: https://docs.google.com/open?id=0BwG6R5 ... 2JTU0xIUTg. The instructions for use are exactly the same as before, but note that there have been problems reported when the environment is installed in a path containing spaces, so avoid places like My Documents or Program Files etc. The old development environment will be no longer supported.

Those of you who pay attention to detail will notice that there is a folder named Mingw64 in the distribution, which contains a zip file and a readme. The zipped file contains the 64-bit version of the compiler, which unfortunately I cannot do anything with since I don't have a 64-bit operating system handy. It is a complete, ready-to-run environment for 64-bits, but anyone who would like to use it will have to unzip the file at the location it is, rename the Mingw64 folder to Mingw (and of course rename the existing Mingw folder to something else first) and rebuild all the game's dependencies, plus the executable of course. In other words, the task requires someone who knows what they are doing. It's not easy, but here it is for whomever would like to take the plunge.

Hi I've downloaded the new development environment today and used it to download download the trunk (revision 5556), which worked no problem. However when I have compiled the trunk several warnings came up whilst compiling:

There are even more warnings reported if you build with GCC 4.7.x (mostly about variables being set but not used). We will look at all of them at some point but for now most of these warnings are pretty harmless. Possible exception is the one about the undefined operation on self->_activeColor.

Likewise - for the moment just ignore them until the dev's work their magic and tweak them away. I've been trialling the new environment for a few days now and not hit any problems aside from them, and as noted they're just reports about unused variables mainly.

Normally the mac compiler is a bit less forgiving but apparently never complained about these. It is a warning about unused variables, so I think it will be safe for all to just delete them. (At least the 3 cases I just checked)

The newer compiler chooses to give warnings for it, because the programmer might have forgotten to add code to use those values he just has calculated.

Likewise - for the moment just ignore them until the dev's work their magic and tweak them away. I've been trialling the new environment for a few days now and not hit any problems aside from them, and as noted they're just reports about unused variables mainly.

Ah well as long as everyone else can see them too, I was worried I'd compiled it wrong but seeing as the instructions hadn't changed I was confused as to how I'd managed it. Indeed they are only warnings and it still compiles fine!