Building Oolite master from GitHub for/by amatures.

[Diziet Sma]

Once it's done, there are some submodules that need to be dealt with. Do:
git submodule update --init

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

Thank you.. you may have just solved the problem I've been having..

[Thargoid]

Indeed, many thanks A_C. With those runes to chant it is quite simple. Will probably ditch the GUI and command line build too I think. One question for the future, can the build environment and the git shell be merged, like you could do with SVN to do the whole repo synch and build in one window?

[Thargoid]

seems to work well, although there's a steep missing as you need to cd into the build directory before downloading the sub modules.

Now going to play about and see what else I can break.

[another_commander]

One question for the future, can the build environment and the git shell be merged, like you could do with SVN to do the whole repo synch and build in one window?

I have not been able to test this, but maybe you could try it and let us know if it works as it should: From the bin folder of your git installation, copy the following files

Code: Select all

getcp.exe
git-receive-pack.exe
git-upload-archive.exe
git-upload-pack.exe
git.exe
gitk
libiconv2.dll

to <Dev Environment Root Folder>\Msys_x2\1.0\bin. If this works, you're all set.

[Thargoid]

With the Git install I have (the Windows GUI one that Gimi mentioned before) I don't have those executables to move. I think I need to pull that off my HD and download a "proper" command line Git suite.

OK now found something suitable, will give that a go instead.

[Thargoid]

OK, pulled the GUI and installed the command line suite (which Zonealarm seemed to imply was a P2P worm...). During the installation had the option to include the set-up in the Windows PATH, so did so and having done so the full build process now works from the A_C build environment without any further tweaking or executable file moving.

So all is good, although I now need to have a file sort-out to get things properly arranged and to ditch the SVN build files.

One last question - is git pull enough to keep both main and submodule components up to date, or is something else needed for the latter? Presuming of course that the build isn't changed to another branch.

[Gimi]

OK, pulled the GUI and installed the command line suite (which Zonealarm seemed to imply was a P2P worm...). During the installation had the option to include the set-up in the Windows PATH, so did so and having done so the full build process now works from the A_C build environment without any further tweaking or executable file moving.

So all is good, although I now need to have a file sort-out to get things properly arranged and to ditch the SVN build files.

One last question - is git pull enough to keep both main and submodule components up to date, or is something else needed for the latter? Presuming of course that the build isn't changed to another branch.

I installed the command line suite and this.
While I run most things from the command line, this GUI runs on top of the CLI and gives warnings (small icons) beside the appropriate command button in order to keep stuff up to date. So if I need to pull two files in a certain branch, a small red "2" appears beside the pull button when I go into that branch. Only downside, it was a pain to sort out the ssh key needed to log onto github.

[Thargoid]

OK, so that wasn't the GUI I had - mine was this one from the github.com site. It worked, but seems a bit more self-integrated and freestanding rather than being based on the CLI.

Will install your one alongside the CLI and see what's what, but as A_C says the command line plus his build environment (with the path option selected at install as noted) is more than enough for a single-window synch and build which is enough for me. I'll leave the actual coding and commits to you clever devs

[Gimi]

OK, so that wasn't the GUI I had - mine was this one from the github.com site. It worked, but seems a bit more self-integrated and freestanding rather than being based on the CLI.
<snip>

Sorry, should have been more clear.

I too used the native GitHub GUI, but quickly found it too limiting. So I threw that out and installed GIT CLI.
While looking around for some easy Git commands I stumbled over this other GUI, and gave it a go.

Useful for looking over resent changes and the logs, as well as it giving me cues when things are out of synch.

[Thargoid]

OK, just to update. Got Gimi's recommended GUI installed now too, and all is working fine. I think the command line (based on A_C's environment set-up) is simplest, but I can see the use of the GUI for seeing exactly what has been done for each commit etc.

But overall the switch from SVN to Git hasn't caused any issue for the amateur build set-up once the relevant support programs are installed (as long as Git is set-up to update the Windows path so the build environment can call it).

So all is well, at least for me and building/updating the current trunk is working fine.

[dertien]

And another idiot wanders in...

OK, pulled the GUI and installed the command line suite (which Zonealarm seemed to imply was a P2P worm...). During the installation had the option to include the set-up in the Windows PATH, so did so and having done so the full build process now works from the A_C build environment without any further tweaking or executable file moving.

So all is good, although I now need to have a file sort-out to get things properly arranged and to ditch the SVN build files.

One last question - is git pull enough to keep both main and submodule components up to date, or is something else needed for the latter? Presuming of course that the build isn't changed to another branch.

I installed the command line suite and this.
While I run most things from the command line, this GUI runs on top of the CLI and gives warnings (small icons) beside the appropriate command button in order to keep stuff up to date. So if I need to pull two files in a certain branch, a small red "2" appears beside the pull button when I go into that branch. Only downside, it was a pain to sort out the ssh key needed to log onto github.

A total noobs guide to getting the source from github on Windows would be something like this:

- create a folder on your C:/ drive (ex: c:/OoliteDev)
- create a github account : https://github.com (no need to download their gui yet)
- Download the client like Gimi said: here: http://www.sourcetreeapp.com/
- install that client and when you get the popup screen with 4 choices, choose the last one (I think it was don't use mercurial)
- on the next screen enter your login and pass of your github account
- launch the gui and click: actions -> open in terminal




- proceed to do the list as A_C suggested:

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.

Now you are ready to compile, but I am also an idiot to that...

[Zireael]

I can confirm SourceTree is a brilliant Git tool, alas, I can't compile...

[dertien]

Haven't figured that one out either, one step at a time I guess. Have found the thread, but still reading:

https://bb.oolite.space/viewtopic.php?f=8&t=5943

[dertien]

Hey Zirael,

Following up on your post, here's what I did to compile:

downloaded this: https://drive.google.com/file/d/0BwG6R5 ... sp=sharing (from original post here: https://bb.oolite.space/viewtopic.php?f=8&t=5943)

unpacked to C:\OoliteDevelopmentEnvironment_LE_20131030 (drag drop using winrar)

browse to C:\OoliteDevelopmentEnvironment_LE_20131030\Msys_x2\1.0 and right click -> run as administrator (win 7)

cmd window opens

navigate to folder where your source is downloaded in my case it's C:\OoliteDev\oolite

in cmd window type:

Code: Select all

cd /c/OoliteDev

then

Code: Select all

cd oolite

then finally

Code: Select all

make debug=no

it compiles everything, then when done navigate to

C:\OoliteDev\oolite\oolite.app using windows explorer, and double click your newly created build exe: Oolite.exe

Voila !

So in a nutshell, you can use the sourcetree terminal to retrieve the files and msys.bat terminal to compile. The sourcetree terminal cannot be used to compile.

[another_commander]

So in a nutshell, you can use the sourcetree terminal to retrieve the files and msys.bat terminal to compile.

Although you may be able to do that, there is no reason for it with anonymous git checkout and pulls. The development environment contains everything that you need for retrieving, updating and compiling the source. Not sure what the "sourcetree terminal" exactly is, but if you have downloaded the development environment you don't need it.