May 08, 2016
I'm tiring of making extern (C) signatures for a million library calls and counting out the offset of members of C structures, to produce analagous D structures. Couldn't I just make a .c file that had my own specialized, opaque, D friendly interface?

I don't really know how to do that. Especially with DUB. Do I put it under "libs"? That seems like the only place you can put external stuff. Do I have to link my wrapper into a PIC shared library, or can I just make a .a static library? Or can I just use .o files?

How do I specify that it look for the C wrapper in my package directory, rather than systemwide? Just "libs": ["./helpers/libchelper.a"]? I sure don't want to make a whole separate revision controlled project installed in /usr/lib just for a chintzy little wrapper for accessing a C library.

I can build any C wrapper binaries in preBuildCommands with just a Makefile, so that's no problem. But I'm not sure how to use them in my program.
May 08, 2016
Well, just messing with it myself, the solution seems to be to make a .a library, link with /lib/libc.a since unlike .o, .a breaks shared linkage, and then refer to it in libs as "$PACKAGE_DIR/libmywrapper.a"

...
	"preBuildCommands": ["make -C $PACKAGE_DIR"],	
	"libs": ["$PACKAGE_DIR/libmymagick.a","ImageMagick","/lib/libc.a"]
...

basically.

Then it doesn't work, because when ImageMagick calls dlopen, dmd somehow switches the string "RegisterGIFImage" with "gif_LTX_RegisterGIFImage" in the resulting executable.

But the wrapper works fine at least.