• cy (17/17) May 08 2016 I'm tiring of making extern (C) signatures for a million library
• cy (14/14) May 08 2016 Well, just messing with it myself, the solution seems to be to

cy <dlang verge.info.tm> writes:

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.

cy <dlang verge.info.tm> writes:

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.