Managing C dependencies with DUB

Question

I was testing DUB and I wanted to install derelcitsdl2 with

"dependencies": {
   "derelict-sdl2": ">=1.2.10"
}

But it immediately throws an runtime error when I run it. It tells me that it can't find the *.so files.

When I build a cross platform project I don't want to be dependent on global system packages like that and this will most likely be a problem on Windows.

Is it possible to run buildscripts with DUB?

Something that could look like this

"dependencies": {
   "derelict-sdl2": ">=1.2.10"
}
"c-dependency-sdl":{
   git clone sdllink && cd sdl && cmake . && make && make install clib
 }

I didn't find an information on the DUB website which tells me that is is most likely not possible.

How do you build your projects for different platforms?

Do I need to write .sh / .bat scripts for this? How would I specify the local search path?

Answer 1

As far as I know, dub does not handle the installation of non-dub dependencies. You can describe system library requirements with the systemDependencies entry, which will be "visible on the registry and will be displayed in case of linker errors", but they will not be installed automatically.

You could use preGenerateCommands or preBuildCommands to execute shell commands like you described above. I would put the install scripts in .sh/.bat scripts like you described above (so they are useable for non-dub users), and then place something like this in dub.json:

"preGenerateCommands-posix":   [ "./setup.sh"  ],
"preGenerateCommands-windows": [ "./setup.bat" ]

On linux, I would typically assume the necessary .so files are available on the standard search path (or available for install through a package manager), especially for something common like sdl.

As far as specifying search path, I just use lflags:

"lflags": [ "-L./ext/sdl/lib" ] (or wherever the local libs are)

Sources: DUB Package Format

Full Disclosure: I haven't actually tried using preGenerateCommands, but it sounds like what you need.

Answer 2

For what it's worth, I turn this problem around and use make/gmake to drive the top-level build. This handles the C/C++ dependencies (which in my case get installed into /usr/local/lib and /usr/local/include) and uses Dub to build the D-language parts (referencing the dependency path as lflags in dub.json).