Building Oolite master from GitHub for/by amatures.

[Gimi]

Gimi simple-minded? Thargoid an idiot? Oh dear... where does that put me?

At a higher state of evolution where menial tasks like compiling software no longer makes sense.

[Cody]

Gimi simple-minded? Thargoid an idiot? Oh dear... where does that put me?

At a higher state of evolution where menial tasks like compiling software no longer makes sense.

<howls> Thing is, at my so-called 'higher state of evolution' (aka old and frazzled) far too many things no longer make sense.

[Thargoid]

Oh trust me, when it comes to hacking together source builds and stuff like that, I'm most definitely an idiot.

I've just about kept the SVN build environment working (with help from A_C), but source code building and linking etc is still largely a blur of files and dependencies floating around in a mess to my mind.

[Gimi]

Gimi simple-minded? Thargoid an idiot? Oh dear... where does that put me?

At a higher state of evolution where menial tasks like compiling software no longer makes sense.

<howls> Thing is, at my so-called 'higher state of evolution' (aka old and frazzled) far too many things no longer make sense.

I recognise those symptoms of ongoing evolution. I guess they er inevitable.

[Cody]

Yep! Gimi... if you can put together a 'how to' that this highly-evolved dumb pilot can follow, I'll be impressed!

[Gimi]

Yep! Gimi... if you can put together a 'how to' that this highly-evolved dumb pilot can follow, I'll be impressed!

I'm looking at it. I will probably beg cim for some additional functionality in the GNU makefile.

I think it's safer to run a make -fMakefile clean after switching branch. Drawback is that that command will delete your AddOns folder, your save games and logs. I was hoping that there was some way to issue an alternative make command that leaves your AddOns folder and save games alone. That will introduce problems of it's own though. My suggestion would be an make -fMakefile tidy command that keeps your save games and AddOns sans debug.oxp with a warning to the fact before running.

Not sure if this made any sense.

Anyway, I still have some experimenting to do.

[Diziet Sma]

Drawback is that that command will delete your AddOns folder, your save games and logs. I was hoping that there was some way to issue an alternative make command that leaves your AddOns folder and save games alone. That will introduce problems of it's own though. My suggestion would be an make -fMakefile tidy command that keeps your save games and AddOns sans debug.oxp with a warning to the fact before running.

Why not just take it one step further and build a 'Trunk' (Master) installer? That's what I used to do back when I was producing the Dizzy's Nightly Builds.. so far as I know, Getafix is still using (albeit possibly modified by now) my customised build script to produce the Windows Nightlys.. it is specifically designed to leave added/generated content and GNUstep configuration untouched. Setting it to leave the logs alone as well is just a matter of commenting out the relevant line in the Uninstaller Section.

You may be able to adapt it to your purposes.. it can be downloaded here:
https://app.box.com/shared/fmtnud1ucm

[Gimi]

Drawback is that that command will delete your AddOns folder, your save games and logs. I was hoping that there was some way to issue an alternative make command that leaves your AddOns folder and save games alone. That will introduce problems of it's own though. My suggestion would be an make -fMakefile tidy command that keeps your save games and AddOns sans debug.oxp with a warning to the fact before running.

Why not just take it one step further and build a 'Trunk' (Master) installer? That's what I used to do back when I was producing the Dizzy's Nightly Builds.. so far as I know, Getafix is still using (albeit possibly modified by now) my customised build script to produce the Windows Nightlys.. it is specifically designed to leave added/generated content and GNUstep configuration untouched. Setting it to leave the logs alone as well is just a matter of commenting out the relevant line in the Uninstaller Section.

You may be able to adapt it to your purposes.. it can be downloaded here:
https://app.box.com/shared/fmtnud1ucm

I fear that is beyond my abilities, but I'll certainly have a look at it. Thanks.

[Diziet Sma]

I fear that is beyond my abilities, but I'll certainly have a look at it. Thanks.

After tweaking it, all you need do is add a call to the script as the final step after compiling.. it will then build an installer that creates a separate 'Oolite-Trunk' installation. Any addons you provide for the trunk version will stay there each time you update. The installer will also take care of uninstalling the old 'Trunk' version before installing the new one.

[Diziet Sma]

Having just looked over it for the first time in ages, the references to SVN version would need adjusting.. possibly Getafix has already done so..

Getafix, could you link to a copy of the current incarnation of the script, mate?

Edit: I'm getting forgetful.. to run the script, you'll need to install NSIS, available for free at:
http://nsis.sourceforge.net/Main_Page

For usage, see the way it's called in the final line of the 'mkwininst.sh' script located in the 'tools' folder of your Oolite source code.

[Thargoid]

Right, I think I need that idiots guide. I've got the git interface downloaded and an account set up. I've found the oolite source on github, but I've no idea on how to use one to download the other.

I can open the shell, but I've no idea of commands to use to point the shell at the repo to pull it down - I'm missing a key step here I think...

[Gimi]

Right, I think I need that idiots guide. I've got the git interface downloaded and an account set up. I've found the oolite source on github, but I've no idea on how to use one to download the other.

I can open the shell, but I've no idea of commands to use to point the shell at the repo to pull it down - I'm missing a key step here I think...

To download source look for a button on the right side called "clone to desktop" on this page.

Click on that and it should bring up a dialogue asking if you want to use the git interface to download.

I'm looking at a guide, but still need to sort out some pitfalls I have come come across. Mainly changing branch and then recompiling seems to a bit iffy. Also, the "gitignore" file needs updating in all the branches to exclude some files in order to avoid confusion.

[Thargoid]

Got it cloning now, but taking forever. Probably not helped by an SVN build also going on.

As you say this may take some getting used to, but it looks interesting.

Editted to add - ok, downloaded and now building with A_C's shell set-up.

Looks OK so far, although not so pleased that I can't find any way to download it to somewhere other than "my documents/github/oolite". Is there some way to change that location do you know offhand?

[another_commander]

I find git's command line very simple to use and I really don't think a gui would be necessary. Here is a very quick guide on how to compile Oolite's source from github. We will assume that we will do all the work inside C:\OoliteDev:

First-time cloning of source tree:
1. Launch git's shell (I use git-bash.bat to do this).


2. At the command prompt type:
cd /c/OoliteDev
git clone https://github.com/OoliteProject/oolite.git


3. The repository will be cloned inside the folder 'oolite'. Once it's done, there are some submodules that need to be dealt with. Do:
cd oolite
git submodule update --init

This will get you the complete source tree, including any and all binary resources (textures, sounds, dependency dlls etc.).


4. Exit git shell.


5. Start up the compiler shell, navigate to the root folder you just cloned (/c/OoliteDev/oolite), proceed as usual to compile.
Note: If your computer has a multi-core CPU, you can use make's -j[number of threads] switch to make it compile ultra-fast. Assuming a 4-core CPU:
make -fMakefile release -j4 will build you a test-release executable, ready to run inside c:\OoliteDev\oolite\oolite.app within seconds.




Subsequent local updates of the source:
1. Launch git's shell.


2. At the command prompt type:
cd /c/OoliteDev/oolite
[OPTIONAL] git checkout branchName [/OPTIONAL] (switches you from master to the branch called branchName)
git pull


3. Exit git shell.


4. Start up the compiler shell, navigate to /c/OoliteDev/oolite.


5. If you have just switched branches, do
make -fMakefile clean
Don't miss this step, otherwise you might end up in a mess of branch-crossed object files, with failure to compile almost guaranteed.


6. Proceed with compiling as usual.

[Gimi]

<snip>
5. If you have just switched branches, do
make -fMakefile clean
Don't miss this step, otherwise you might end up in a mess of branch-crossed object files, with failure to compile almost guaranteed.
<snip>

Thank you AC. This may well be how I end up doing things, as it gives more control and allows me to use different folder for different branches if I so choose. I'm still exploring.

Word of warning though.
The command make -fmakefile clean will delete the entire oolite.app folder including any save games as well as the entire OddOns folder. Move/copy them out before you run the command if you want to keep them.

Which leads me to my next question. Can I have a modified clean command that leaves AddOns and Save games intact or that automagically moves those folders elsewhere. My suggestion is make -fmakefile tidy.

This will act as a safety feature for us simple minded folks.

Edit: Should I add this request to the issue tracker?