Merge pull request #1 from jaydg/update_to_151

Update to libtcod 1.5.1

.gitignore

@@ -1,6 +1,4 @@
-*.o
-*.obj
-a.out
-*.exe
-genfunctionsmod
+bin/
 
+.dub
+dub.selections.json

README.md

@@ -0,0 +1,51 @@
+# libtcod-d 1.5.1-1
+
+libtcod-d is a set of bindings for using the excellent
+[libtcod](http://roguecentral.org/doryen/libtcod/) in the D programming
+language.
+
+The DLL (libtcod.so on Linux, libtcod.dll on Windows) is dynamically loaded
+on start up, not linked at compile time.
+
+It searches for libtcod_debug.so, and if it can't find that, then libtcod.so
+on the executable's path (or dlls if on Windows). The current release build of
+libtcod.so 1.5.1 is lacking the functions `TCOD_mouse_includes_touch` and
+`TCOD_sys_get_sdl_window`, and will fail on attempting to load those functions.
+
+ATTENTION: the x86_64 version of the Linux library seems to be very unstable
+and the demo application crashed immediately upon startup. The x86 variant
+works almost fine, though.
+
+To try the samples, run `dub run -a x86 -c samples_d`
+
+The bindings are a strict port of the C API, so refer to libtcod
+documentation for more details. If I can get motivated, an object
+wrapper that would be similar to the C++ API may be forthcoming, so watch
+this space.
+
+For comments and complaints, use the issue system on GitHub.
+or email me at b (dot) helyer (at) gmail (dot) com.
+
+## Developing with libtcod-d
+
+The libtcod-d code is maintained in a Git repository at github.org.
+If you are also using Git for your own project, you should consider
+using "git submodule" to add the libtcod-d repository as submodule
+under your project. If you have experience with svn externals, git
+submodules are a similar feature.
+
+Git submodules allow your repository to point at a single, static point
+in a separate repository as a child element. This avoids having to
+copy the code into your repo, etc.
+
+Git submodules use a frozen point - not "HEAD" or any of the branch
+heads - so that you can develop against a stable background. If you
+want to update the submodule to a later version of its own code, you
+have to do that explicitly. This keeps your environment stable until
+you ask for it to change.
+
+Of course, the best reason for using submodules is that you can clone
+the libtcod-d repository on github (or somewhere else), point your
+submodule at your clone, and make updates to the libtcod-d sources
+within the submodule directory. Then you can contribute to libtcod-d
+by pushing your changes back upstream. :)

dub.json

@@ -0,0 +1,34 @@
+{
+	"name": "libtcod-d",
+	"description": "Bindings for using the excellent libtcod",
+	"homepage": "https://github.com/bhelyer/libtcod-d",
+	"copyright": "Copyright © 2012, Bernard Helyer",
+	"authors": ["Bernard Helyer", "Joachim de Groot"],
+	"license": "BSD",
+	"copyFiles-linux-x86": ["libs/linux/x86/*"],
+	"copyFiles-linux-x86_64": ["libs/linux/x86_64/*"],
+	"copyFiles-windows-x86": ["libs/windows/x86/*"],
+	"dependencies": {
+		"derelict-util": "~>3.0.0-beta.2"
+	},
+	"configurations": [
+		{
+			"name": "default",
+			"targetType": "sourceLibrary"
+		},
+		{
+			"name": "samples_d",
+			"mainSourceFile" : "examples/samples_d",
+			"targetName": "samples_d",
+			"targetType": "executable",
+			"targetPath": "bin"
+		},
+		{
+			"name": "simple",
+			"mainSourceFile" : "examples/simple.d",
+			"targetName": "simple",
+			"targetType": "executable",
+			"targetPath": "bin"
+		}
+	]
+}