Oolite Bulletins

Ahruman wrote:

Looks like HTTP access is down, but SVN protocol access is up. Gimi, try svn checkout svn://svn.berlios.de/oolite-linux/trunk .

Thank you, worked a treat.
Can I also do "svn up svn://svn.berlios.de/oolite-linux/trunk" Can't test as it's downloading all right now.

You should just need “svn up”.

Until http://terrastorage.ath.cx/Marmagka/c0a ... 110212.zip is up again, you can temporarily get a copy here : http://www.adrive.com/public/856e39bfda ... 19a30.html
(mainly because I read how Captain Murphy could not download this package yesterday)

Minor things I have noticed in Win XP pro SP1, NTFS 5.1 :

- Does not like to be installed / unzipped to "funny" pathnames, e.g. somewhere with a space in the pathname. (You can probably edit some config file so it would accept pathnames with any strange signs in it, but I did not bother looking into it.)
- On usage it creates a drive O: , which maps the drive it is running from (in my case D: , so drive D: is visible twice in windows explorer.).
This drive O: remains even after exiting msys, but after a reboot it is gone. No harm done.

But it works fine as usual.

Thanks Snork. First self compile of r4642 up and running.... Just had to manually create the AddOns folder.

edit 2 add - just as a side note my security software is flagging svn.exe, version 1.4.3.23084 as insecure and is suggesting an upgrade to version 1.6.17.0. I guess it's safe to assume that upgrading would be a bad idea?

Capt. Murphy wrote:

just as a side note my security software is flagging svn.exe, version 1.4.3.23084 as insecure and is suggesting an upgrade to version 1.6.17.0. I guess it's safe to assume that upgrading would be a bad idea?

You could try updating it and fall back to the 1.4.3 version if things don't work. Making a copy of the svn folder before upgrading would be the easiest way of doing this.

Edit: Now that you have a build of the game from source, feel free to start hacking the code itself. Any ideas or features that could come out as a result and are considered cool enough could be included in the mainline post-feature freeze. This goes also for anyone playing with the source at this time. Hey, be an Oolite core contributor, you know you want to!

It doesn't seem to be as easy as replacing the svn folder with a newer release as MINGW32 doesn't recognise svn as a valid command anymore. No big deal - the said security software has an ignore function....

Also found NSIS to create an installer (purely for personal use). But amusingly as I had put a full AddOns folder in the trunk folder it appears to be including all the OXPs in the installer package - doh.

I am sure to be poking around the code, but don't expect any great things anytime soon. My first project is to see what I can break by trying to add some extra JScript methods for changing the player ship via script.

Capt. Murphy wrote:

But amusingly as I had put a full AddOns folder in the trunk folder it appears to be including all the OXPs in the installer package - doh.

Yep, I think that somewhere in the build instructions there is a command to copy the whole addOn folder into the build. On the mac, every single file has to be defined.
I remembered the first time I added a file to the project. It is than uploaded to berlios and every subscriber that updated the project than gets the file on his local computer. Somehow I had my doubts if I did it correct and asked another_commander if things worked for him. And yes, it was now part of his builds also, so I thought I did it correct. But later the file seemed to be missing in all Mac builds. It was in my build because I added it manually for testing and the normal build process does not delete unused files automatic. (therefor you need the 'clean' command).

Good to hear that you now set up a build system yourself. You probably noticed already that this is even faster than downloading the nighties. (except on the first time of course). You now only have to download the changes.

Come across an oddity - when I've done an initial svn co and a make debug=0 build, and a few revisions later svn up which confirms an update, then do another make debug=0 build, the resulting oolite.exe when run reports in the log that it is still the previous build/revision.

Similarly a make -fmakefile pkg-win-snapshot debug=no over an existing build after an svn-up makes an installer that's file-name is for the expected revision, but when installed produces an oolite.exe with no watermark and the log again reports previous build/revision.

If it's useful I can tell you what files in the trunk folder and subfolder were updated during the svn up and the build

Sounds like you somehow still got the resources files from the previous version.
Maybe you accidentally marked some of the files inside Resources as read only. If that's the case, make won't be able to do anything about the version reported in-game.

Delete the oolite.app directory, recompile, and everything should be ok again.

Loads of errors when compiling 4733 "The Easier Way". Also see that the latest nightly completed with multiple warnings. I assume that this is related to all the updates and change of compiler that Ahruman did yesterday. Does the change of compiler etc mean that Building from source needs to update the build environment or something?

Edit: Doing a fresh checkout just to make sure.

Edit 2: Fresh checkout gave the same errors and warnings.

Gimi wrote:

Loads of errors when compiling 4733 "The Easier Way". Also see that the latest nightly completed with multiple warnings. I assume that this is related to all the updates and change of compiler that Ahruman did yesterday. Does the change of compiler etc mean that Building from source needs to update the build environment or something?

No it only means that some of the changes are probably not compatible with the current windows compiler. I assume that the window experts can sort this out. And even when there are lots of errors, it still can be just one error that causes this.
Your build environment on windows should still be okay. Even on the mac, the old environment still works. The changes were there so it now also runs on the new Mac compiler. (see Mac forum)

I regret to have to let you know that currently I cannot allocate any time for re-constructing the build environment with a new compiler. What I could do - but not sure when - is check whether the errors currently coming up could be fixed without changing out gcc for clang.

BTW, this could be a good time for someone to step up and claim the Oolite Windows build's maintainer seat, especially if the change to clang is deemed unavoidable for all platforms. I would be willing to offer as much help and support as I can, but this could be limited and dependent on time available.

There should be no need to change the Windows build environment. The problems at the moment are side effects of the Mac-specific changes.

I can fix the problems in the nightly log, but since it seems to be stopping at the first error it may take several days until it builds properly.

Should be fixed in r4734.

Got a lot further this time, but ended with the following error: