Building Oolite Windows from source - The Easier Way

[Kaks]

Glad I managed to help somewhat!

[another_commander]

Please be advised that we have now switched the version of GCC used to build Oolite for Windows from version 3.4.2 to 4.3.2. This has enabled us to have just one compiler for building the new JavaScript engine, GNUstep runtime and the game itself (3.4.2 was able to build only the game).

In addition to that, we are now using GNUstep 1.20.1 on the Windows port. All this means that the delelopment environment we've had until now is not supported anymore. I have uploaded a new DevEnv on http://terrastorage.ath.cx/Marmagka/96c ... 110207.zip . Anyone building from source using the instructions in the first post of this thread should switch to the latest environment.

If you encounter problems using the new development system, please let us know.

[Gimi]

@Another_Commander
Could you update the last edited date on the first post. I jumped back and forth a few times to make sure I downloaded the correct version. First post says last edited in June 2010.

[another_commander]

Done. I thought the date would be automatically updated after an edit, but it looks like the 'reason for edit' box must be filled in first. Anyway, sorted now. Thanks for the heads up, Gimi.

[Svengali]

Thanks a lot a_c - works superb!

[another_commander]

New update to the Windows build environment. This time, we have these new things on:
1. Small update to the gnustep-base and Objective-C runtimes used for building the Windows version. It is related to exception handling and, under normal conditions, this change should be fully transparent to the users who just want to build Oolite from source.
2. This is teh biggie: Kaks has performed some digital wizardry on the pre-existing setup and the result is that now we have a fully portable environment, which can be installed on any drive. In theory, it should be runnable even from USB now, but I have not tested that far yet. Careful if your system is using the drive letter O: You will have to edit two files to change O: to an unused drive letter, but, let's face it, how many of us are using drive O:?

That's it, I hope that this will be the version that will stay around for a while without any more changes. As always, if you find anything going wrong with it, please let us know.

[Kaks]

Ooh, I didn't break stuff in the end then - good to know!

Edit: oops, some instructions on the first post look like they need some updating. May I suggest:


Once unzipped, you must run the msys.bat file: assuming you unzipped the development environment to C:\ooDev\, msys is inside
C:\ooDev\msys_x\1.0. You can create a shortcut to desktop for this file if you want. Once run, the environment will start up.
If you use a different directory, replace C:\ooDev\ with the actual directory your development environment is in.
The rest of the steps are:

1. Create our working directory:

Code: Select all

mkdir /o/myoolite

to create a folder called myoolite (it will show up as C:\ooDev\myoolite\ ). This is where we will check out the code.

Code: Select all

cd /o/myoolite

to enter our working directory.

[another_commander]

Edited for the first point. However, Oolite can really be wherever we want, it is not necessary for it to stay under any particular drive. I have left D: for the sake of simplicity in the first page, with a note of the above.

[Kaks]

Good point!

[Frame]

just wanted to note that with the new updated developer enviroment as of 12 feb, and the hacked Obj C build, users of 64 bit windows vista and very likely windows 7.. cannot start up the the rxvt terminal program or the sh.exe program as GNUstep is buggy in that respect, wades post 10 posts back describes the same problem...

19-21 is likely broken on windows 7 and vista... which is the two latest releases of Windows, and every new PC today is 64 bit..
the Oolite Developer enviroment is outdated in that respect... There is even a mention of it, in the msys.bat file about how "hopefully" 64 bit machines now can run GNUstep... which seemed to be have solved in 1.22+ but not version prior to that...

There is a need to update Oolite Developer enviroment to at least Gnustep 0.22 which is what I used in my last succesfull build, but that i cannot use now due to the hacked Obj c build cannot build Oolite anymore.

Other than that, someone need to correct the wiki information, as that certainly does not hold true anymore...

[Gimi]

just wanted to note that with the new updated developer enviroment as of 12 feb, and the hacked Obj C build, users of 64 bit windows vista and very likely windows 7.. cannot start up the the rxvt terminal program or the sh.exe program as GNUstep is buggy in that respect, wades post 10 posts back describes the same problem...

I'm on Win 7 Professional, 64bit and both start up fine. I did update the environment after Feb 12, and I use the "Easy method for building trunk" setup. Don't know if that is relevant though.

[another_commander]

just wanted to note that with the new updated developer enviroment as of 12 feb, and the hacked Obj C build, users of 64 bit windows vista and very likely windows 7.. cannot start up the the rxvt terminal program or the sh.exe program as GNUstep is buggy in that respect, wades post 10 posts back describes the same problem...

19-21 is likely broken on windows 7 and vista... which is the two latest releases of Windows, and every new PC today is 64 bit..
the Oolite Developer enviroment is outdated in that respect... There is even a mention of it, in the msys.bat file about how "hopefully" 64 bit machines now can run GNUstep... which seemed to be have solved in 1.22+ but not version prior to that...

There is a need to update Oolite Developer enviroment to at least Gnustep 0.22 which is what I used in my last succesfull build, but that i cannot use now due to the hacked Obj c build cannot build Oolite anymore.

Other than that, someone need to correct the wiki information, as that certainly does not hold true anymore...

This is mostly incorrect.
1) GNUstep 1.20.1 used by Oolite is fine in all respects. Actually, the version shipped with Oolite fixes an integer bug that exists in the official version of GNUstep, so it is better than the official thing.
2) The breakage in Windows Vista 64 is not confirmed for all systems and has nothing to do with the version of GNUstep distributed. It is most likely a Vista bug, as seen here: http://sourceforge.net/tracker/?func=de ... up_id=2435 . The link leads to proposed MSYS Core downloads that reportedly fix the problem, but I cannot confirm this as I do not have this OS on my computer.
3) We have already people on Win 7 64 bit building Oolite just fine with the 12 February environment, so it is by no means outdated.
4) The "hacked" Obj-C build is now a requirement for building Oolite on Windows, since native Obj-C exceptions must be supported in all platforms and the official GNUstep distribution does not support this.
5) GNUstep 0.22 is the package referring to gnustep-base 1.18.0, which is already older than the gnustep-base 1.20.1 we use now. Going to 0.22 would be a downgrade, not an upgrade. Additionally, we are in code freeze so nothing is expected to change before next stable.

It would be nice to have some more reports from users of Windows Vista/7 64-bit systems who have managed to use the package successfully.

[Gimi]

As I have posted above, I'm on Win 7 professional, 64bit. I updated the environment after Feb 12, and rev 4426 just completed building with no errors.

Edit: Are there other things I can try to trigger the bug other than just building trunk. (I will need detailed instruction, fed to me with a teaspoon).

[Frame]

Videod the bug...

http://www.youtube.com/watch?v=HpxypJghkVs

[Frame]

did not see to two posts above.. an in the link another commander refers to. i can find no patch.. only some information on howto correct the code in msys code...

Edit...

So as i understand it, it is a vista specific problem... now that is just wonderfull.. how come I allways run into specific problems..
Cheers Frame..