Opening Derelict’s Doors

A pull request was recently submitted to Derelict3 adding a binding for the PostgreSQL library, libpq. My automatic reaction was to reject it. Over the years, I’ve been conservative in allowing new packages into Derelict. My focus has always been on multimedia/game libraries. The biggest reason is that I’m the one responsible for maintaining everything and keeping all the bindings up to date. In the past, people have submitted packages and then I never heard from them again. Making sure a binding is up to date can be rather time consuming when you do it all by hand. So I’ve always felt that fewer is better when it comes to which packages come into Derelict.

While at DSource, I was fortunate to receive a lot of community contributions in terms of bug reports and zip archives of new packages, but very rarely received patches to add incremental fixes or changes. Since making the move to github, I’ve gotten a steady stream of pull requests that keep things up to date without any effort on my part. That’s a really big deal for me, given that I’m borderline dysfunctional when it comes to the number of projects and activities I have going on. I still get bug reports that don’t have an accompanying pull request, but much fewer than before.

After a brief conversation in the libpq pull request thread, and given that github is a game changer when it comes to project maintenance, I’ve changed my mind. So from now on I’m willing to accept any dynamic bindings into Derelict as long as they are to a library with a C interface (not ready to deal with C++ bindings yet). I’ll see about putting up a style guide to try and keep some consistency.

So if you have a C library you’d like a binding for, or a static binding you’d like to Derelict-ify, feel free to submit a pull request for it. I’ll be less likely to refuse it from here on out.

Tiny Redis 1.2

Tiny Redis 1.2 has been released. From the announcement:

This release introduces some improvements to remove common boilerplate when dealing with types in D and Redis. It also uses some of D’s magic functions to make type conversions and iterations simpler. The documentation has been improved a bit. Plus, as usual, some more bug fixes.

Looks like more than just a simple binding. Looking at the web page makes me want to use it myself, even though I have nothing I need to use Redis for at the moment!

Compiling GLFW3 for use with Derelict

It seems some people have had some difficulty in getting the GLFW3 shared library compiled to use with their Derelict-based apps. Rather than post a writeup in my forums, where very few would see it, I figure it’s a good candidate for a blog post. Of course, the steps given here aren’t just for D developers. Anyone wanting to use GLFW3 as a shared library can follow along. And while most of the info is Windows-centric, users on other platforms will likely already have the required tools installed and simply need to follow the steps in the Compiling section below.

Tools

D users are likely going to have git installed already. Those who don’t, really should. It’s not an absolute requirement, as you can download the source for both Derelict and GLFW as a zip archive, but it will certainly make your life a bit easier. So if you’re a Windows user who doesn’t have git already, I recommend Git for Windows. Download it, install it, and make sure the install directory is on your path. This is a command line tool, though, so if you’re a total rube when it comes to git or have a strong aversion to command line tools, you might be more comfortable with GitHub for Windows, a GUI interface that handles most of the icky command line stuff for you behind the scenes. I’ll be focusing on the former, as that’s what I use and am familiar with. Besides, you’ll need to use the command line to build anyway.

Next up is cmake. This is an important tool to have in your toolbox these days if you are working with C or C++ libraries. A number of projects use cmake to manage build configurations. It comes with both a command line tool (cmake.exe) and a GUI interface (cmake-gui.exe). My instructions will be for the command line tool, as that’s all I ever use. And if you can’t figure out the GUI via the interface itself and the documentation, then maybe you ought to give up on this programming thing and find another hobby. You’ll also want this one on your system path.

Of course, no building of C libraries is going to get done without a C compiler. I haven’t touched Visual Studio in years, but if you’ve got it or another compiler other than DMC already installed, you can go to the next step.  I don’t know if cmake works with DMC, or if GLFW will compile with it and as I’m typing this on the POS at my hot dog shop (slow day) am neither able nor inclined to find out. Instead, I’ll tell you to go off and download the latest version of mingw-get. When you run the installer, you’ll be given a choice of packages to install. At a minimum, you’ll want the gcc and msys packages. Technically, you can get by without MSYS, but in my experience you’ll be much happier using it rather than the Windows command prompt in the long run, particularly if you want to start compiling libraries that aren’t set up to use CMake.

Compiling

Now that everything’s installed, open up MSYS and execute this command:

cd /c

Remember, MSYS is a unlix-style command line interface. The C:\ drive you’re used to is configured as /c instead. cd into a directory somewhere to clone the glfw3 repository. For this guide, let’s assume you create a directory off of C drive called ‘libs’.

mkdir libs
cd libs

Now grab the glfw3 source and navigate to the new directory.

git clone https://github.com/elmindreda/glfw.git
cd glfw

Now it’s time for CMake. We need to tell it two things. First, we are running in MSYS, so we need to tell it to give us “MSYS Makefiles”. MSYS has support for shell scripting in makefiles, whereas “MinGW Makefiles”, which is what you want for the Windows command prompt if you aren’t using MSYS, does no such thing. Second, you need to tell cmake that you want a shared library. glfw is configured by default to build static libs, the recommended way to use it these days. However, for Derelict we need the shared lib. So the cmake command needs 2 switches, like so:

cmake -G"MSYS Makefiles" -DBUILD_SHARED_LIBS=1

If you are using Visual Studio, run cmake with no arguments to determine the string you need to pass to -G.

After cmake has done its work, you should have a properly configured Makefile in your glfw directory. If instead you happened to get errors, don’t ask me about them, please. I always ask Google and he usually has the answer. If Google is clueless, your next course of action should be to head to #glfw on freenode.net where glfw support is handled.

So with your freshly minted Makefile sitting there in the glfw directory, we’ve come to the final step.

make

Done. Once compilation completes, you should find the glfw DLL in the src subdirectory. Drop that into a directory with your D app that uses Derelict, call DerelictGLFW3.load() in your code, and away you go.

Now not only do you have glfw compiled, but you are also ready to compile other C libraries you may need for current or future programs, like SDL2 or SFML2. And don’t look at me. That’s an exercise for the reader.

DerelictSDL2 Breaking Changes

A new snapshot of the SDL2 tree was recently released. I was going to catch the binding up to it, but there have been more recent changes in the SDL2 repository. Most importantly, there’s a new cmake build system that does not exist in the snapshot, so I decided to get caught up there instead (changeset 6685 is the latest compatible at the time of this post). Windows users can use the precompiled DLL I’ve uploaded to github.

It’s quite possible that I missed something, as I didn’t have the old snapshot available to diff against. Also, SDL2 development is moving along pretty well, so there could likely be more API changes before the next snapshot is released. I’ll play the catch-up game until then, but I do want to go back to basing the binding on snapshots at that point.