Thank you, thank you, thank you for this guide! I just managed to compile and test a certain tweak of mine (and no, I am not talking of the failed attempt to de-hardcode the number of systems)
Now you have to begin the long and tiring journey of trial and error of coding and re-coding...
Thanks, last night I followed the instructions in the first post of this thread and it worked first time flawlessly on Windows 8 ultimate 64 bit
I then wrote a bash script (comprising of the last bit) to update and compile it which I tested this morning again it worked flawlessly
I hope to become an active contributor to this project. we'll see just how good (or bad) I am at coding in C.. lol
we'll see just how good (or bad) I am at coding in C.. lol
Welcome to the forums, BlueSteel.
Note that Oolite uses Objective-C, rather than C, as its language. If you're already familiar with C then there's a few extra bits of syntax mostly related to how objects are defined, used and memory managed, plus an extensive (but generally well-documented) standard object library in the form of Cocoa or GNUStep (depending on OS). C-style code is also used in situations where maximum speed and lower-level memory access is required, generally when interfacing with graphics and sound libraries, but mostly that's avoided. If you're not already familiar with C, this information will probably change which language tutorials and references you consider.
When you do the final build, you need something like "make -fMakefile release-snapshot" (without the quotes) in the root of your trunk code set-up after you do the git download or update.
When you do the final build, you need something like "make -fMakefile release-snapshot" (without the quotes) in the root of your trunk code set-up after you do the git download or update.
So I just ditch the "debug=no" -part and insert "-fMakefile release-snapshot" instead?
Yes, or basically just type the line above. Another segment I use (if you have a multi-core CPU) is -j4, where that tells the compile to use that number of cores (4 in the -j4 case) to speed things up a bit.
Before you do it though, you probably should "make clean" which will remove the previous build, as if you build one build target over another you can get weird problems of files not coming out right.
So basically the bold/italic bits below:
git pull (to update, or if necessary do your repository download if it's the first time)
make clean (if you've done a previous build of another target)
make -fMakefile release-snapshot (to make the code).
Yes, or basically just type the line above. Another segment I use (if you have a multi-core CPU) is -j4, where that tells the compile to use that number of cores (4 in the -j4 case) to speed things up a bit.
Before you do it though, you probably should "make clean" which will remove the previous build, as if you build one build target over another you can get weird problems of files not coming out right.
So basically the bold/italic bits below:
git pull (to update, or if necessary do your repository download if it's the first time)
make clean (if you've done a previous build of another target)
make -fMakefile release-snapshot (to make the code).
[/color]
Cool, thanks.
Where do I put that -j4 ?
Before -fMakefile? (making the command: make -j4 -fMakefile release-snapshot)
@Zieman - doesn't matter, as long as the command (make) comes first and the target (released snapshot) is last. The other bits (starting with -) are make parameters and their keys, and can be in any order.
And as a note, the 4 in the -j4 may need to be able tweaked depending on how many cores your system has and that you want to use.
Once you have downloaded it, place it in your Msys home directory. For me that is C:\Msys_x2\1.0\home\Richard. Next open up the console (with msys.bat) and type:
![[EliteWiki]](/images/elitewikismall.png){kind=small}
Far Arm ships
.
