• Install GCC either from your package manager or use MSYS+MinGW on Windows.
  
• Install SDL development libraries either from your package manager or get them from the SDL site.
  
• Get the source code of JA2-Stracciatella either via SVN from svn://tron.homeunix.org/ja2/trunk or get a source package
  
• Copy config.template to config.default, edit the resulting file: Uncomment ONE language, optionally uncomment some build options.
  For MSYS+MinGW uncomment the parts specific to it regarding SDL and adjust the path to SDL as necessary
  
• Build it by typing make (or gmake on some platforms)
  
• Start the game once, it will generate a config file .ja2/ja2.ini (or JA2/ja2.ini on Windows) in your home directory and terminate. Edit the file and adjust the path in their to point to your Jagged Alliance 2 data files.

# NOTE: This file is ONLY intended as template config file for manual builds.
# If you are building a package (or ebuild, spell, source rpm, ...) do NOT
# modify this file, use sed or whatever. In fact do NOT use this file AT ALL.
# Just pass parameters to make. This is much simpler and way less error prone
# this way. This file is NOT intended for package building. For a package
# just use
# make LNG=$YOUR_LANGUAGE PREFIX=$YOUR_PREFIX
# as build command and maybe some more variables, though on a sane system this
# should not be necessary.

# Uncomment exactly ONE of these
#LNG := DUTCH
[color:#CC0000]LNG := ENGLISH[/color]
#LNG := FRENCH
#LNG := GERMAN
#LNG := ITALIAN
#LNG := POLISH
# Russian BUKA Agonia Vlasti release
#LNG := RUSSIAN
# Russian Gold release
#LNG := RUSSIAN_GOLD

#JA2BETAVERSION := yes
#JA2TESTVERSION := yes
#JA2EDITOR := yes
#WITH_DEMO := yes
#WITH_DEMO_ADS := yes
#WITH_FIXMES := yes
#WITH_MAEMO := yes
#WITH_SOUND_DEBUG := yes

#CFLAGS += -g
#CFLAGS += -Werror

# Specify here were the Jagged Alliance 2 data files are located
#SGPDATADIR := /usr/local/share/ja2
SGPDATADIR := "C:/Program Files/Jagged Alliance 2 Gold/data" #actually just curious if this is #correct in hindsight its working but sgp is a folder in the source is it not?


# Tunables for installation. The default values are shown
#PREFIX := /usr/local
#MANPREFIX := $(PREFIX)

#INSTALL := install
#INSTALL_PROGRAM := $(INSTALL) -m 555 -s
#INSTALL_MAN := $(INSTALL) -m 444
#INSTALL_DATA := $(INSTALL) -m 444


# Below are some example variable overrides for MSys/MinGW
# If you set CFLAGS_SDL and LDFLAGS_SDL explicitly, then SDL_CONFIG is ignored

[color:#FF0000]SDL_CONFIG := D:/MinGW/bin[/color]
#SDL_PATH := ../sdl-1.2.11
[color:#CC0000]CFLAGS_SDL := -I D:/MinGW/include/SDL
LDFLAGS_SDL := -L D:/MinGW/lib -lmingw32 -lSDLmain -lSDL[/color]

How to Install SDL Under MinGW

--------------------------------------------------------------------------------

Introduction
SDL is great and it lives here. But if you're not already a guru, it can be difficult to install, and there aren't many if any step-by-step instructions for getting it working. So, if you're struggling to install it under MinGW, this page might be helpful.

Installing SDL
These are the steps I took to get SDL 1.2.9 running, starting with MinGW and MSYS already installed, and using Windows 2000/XP.

Download and unpack SDL
On the SDL Web site, go to the download section for the current version (1.2.9 at the moment).
You're given a choice of Source Code, Runtime Libraries, or Development Libraries. Assuming you want to write programs that use SDL, and you just want to get up and running without being bothered compiling the source code yourself, you need the Development Libraries bit of the page.
You're installing it under MinGW, so [color:#CC0000]download SDL-devel-1.2.9-mingw32.tar.gz [/color](assuming 1.2.9 is the current version).
Unzip and unpack that file into a temporary directory on your PC. You can delete the directory when you've finished installing. Let's assume you've unpacked the file into /temp/. You'll need something that can handle .gz and .tar, but that's probably in MinGW/MSYS already. Personally I use WinNavigator which deals with them nicely.
Install SDL files for the compiler
Find your MinGW directory, the one with the bin, doc, include and lib directories in it. Let's assume it's /mingw/
[color:#CC0000]Create a new directory to put the SDL header files in: /mingw/include/SDL/
Copy all files (30 of them in SDL 1.2.9) in /temp/SDL-1.2.9/include/ to this new directory. [/color]
[color:#CC0000]Copy all files (4 of them in SDL 1.2.9) in /temp/SDL-1.2.9/lib/ to /mingw/lib/ [/color]
Find your MSYS directory, the one with the bin, doc, etc, and home directories in it. Let's assume it's /msys/
[color:#CC0000]Copy the file /temp/SDL-1.2.9/bin/sdl-config to /msys/bin/sdl-config[/color] I chose /msys/bin/ because you can be sure that anything in there will always get executed regardless of which directory you're currently in. When you compile an SDL program you need to execute the file sdl-config on the compilation line (more below).
Copy the SDL DLL and tidy up
[color:#CC0000]Copy the file /temp/SDL-1.2.9/bin/SDL.dll to c:/WINNT/system32/[/color]. As that directory will be in your PATH, it ensures that any SDL program you write will find the DLL and you can keep just one copy on your disk. If your Windows drive is something other than c: then change accordingly.
Delete /temp/SDL-1.2.9/
You should now have a working SDL installation and you can write some code.

Here's a small program to get started and to test everything's working.

#include
#include "SDL/SDL.h"
// include the SDL headers you put in /mingw/include/SDL/

int main(int argc, char *argv[]) {
// with SDL, you need the argc and argv parameters

printf("Hello world ");
// with SDL, anything you printf will get printed to the
// file stdout.txt in the current directory, not to the screen
}

How to Compile an SDL program
To compile an SDL program, use this:

gcc filename.c `sdl-config --cflags --libs`

[color:#CC0000]Note that you use backticks (SHIFT + ~), not normal apostrophes[/color]. The file sdl-config will get executed (which is why you copied it to /msys/bin/ so that you can be sure that it will get executed) and will pass its output to gcc, in a sort of magical ritual that I don't understand.

SDL_CONFIG := [color:#CC0000]D:/MinGW/[/color]bin
#SDL_PATH := ../sdl-1.2.11
CFLAGS_SDL := -I [color:#CC0000]D:/MinGW/[/color]include/SDL
LDFLAGS_SDL := -L [color:#CC0000]D:/MinGW/[/color]lib -lmingw32 -lSDLmain -lSDL

D:/MinGW/bin is where my sdl-config is

BTW D:/MinGW/bin is not some random director its where I put sdl config which is the bin directory in Mingw so it should be in its path and able to be executed from anywhere, msys is on my c drive

git-clone http://oldsch00l.com/git/ja2-stracciatella.git

mkdir release
cd release
cmake ../.
make or make -j2 (if you have a multicore system)

what about Stracciatella + Wildfire? Would the datafiles from WF work directly?

No way to make the externalizations (xml files) compatible? I heard mention of externalizations for this project. Could anything possibly be learned (or better yet ported over) from the 1.13?

As for items referenced by name instead of number that seems to be the way most coders want to do it these days but I wonder what is so bad about the way the game originally did it (i.e. referencing by number) at least for the main items xml? I agree that dependent xmls would be much better referenced by name so that modders could find them easily. The item numbers may look a little restricting at first glance but consider the fact that were items referenced by name you could no longer have two identically named items behave in a different manner.

For instance, for my project I needed a workaround for the fact that weapon reliability (and even ammo deficiencies) are not addressed in the current system. To add these factors into my mod I created several identically named items which use different stats. So you may find a version of a rifle that has very crappy preformance compared to another you might find with much better preformance due either to wide variances in production values or even age of the weapon. There are sometimes slight hints in the description to let you know what is going on but in the case of ammo there currently is not. Some badly produced ammo behaves differently than standard.

[...]

To make 1.13 compatible would be a mammoth task to the point it's probably going to cause more problems than features it adds. Not saying it can't be done, but it certainly is a lot of work. Maybe you'd like to keep an eye on the SMP project of which one of the aims is to make the JA2 engine more modularised and up to date