C Wrapper FYI: libpng, libsane, and libharu

[Chad Joan]

I just spent a few days creating a wrapper for libpng.  It isn't 
perfect, but I figured someone might want to know about this code.  I 
also made libsane and libharu wrappers earlier.

libpng was the real pain of all of these, so I hope this saves someone 
about 3 days of work.

The wrappers are currently housed in my (hobby) scanning automation project:
https://github.com/chadjoan/autoscan/tree/master/src

The libpng wrapper converts the setjmp/longjmp error handling of the 
libpng C API into thrown exceptions in D code.  It does this using C 
code so that the C compiler can get the setjmp right for sure, and also 
allows the C compiler to decipher the versioning macro maze and prevent 
linking breakage by pushing missing function detection into runtime. 
This requires generating a bunch of code.

The libsane wrapper (as in Scanner Access Now Easy) is much simpler.  It 
also features some tests that can be compiled (on both C and D sides) to 
make sure that the type sizes and struct layouts agree on your system. 
Furthermore, a work-in-progress higher level abstraction for sane 
(sane/abstraction.d) provides a Range-based interface for some of sane's 
operations (the Range stuff is not API-stable at all, use at your own risk).

The libharu wrapper isn't too noteworthy: just your basic extern(C) and 
#define->enum stuff, and not even entirely complete.  I am unlikely to 
put future work into this wrapper.  I am probably going to avoid using 
PDFs because they can't be reprocessed easily once I generate them.

Caveats:
- The libpng wrapper lacks good build scripts.  It is currently using 
some shell scripts that hardcode usage of gcc/dmd.  I don't have time to 
make more appropriate scripts.  Windows users will have to bring their 
own entirely.
- The libsane wrapper also lacks build scripts, but is so simple that 
you can probably figure it out.
- The libpng and libharu wrappers both lack self-tests for type-size and 
struct-layout agreement.
- The libharu wrapper is not a complete or exhaustive wrapper by any means.
- These are all for static linking, but some of these might be more 
appropriate to dynamically link.  The only reason this isn't done right 
now is because of the work it would require and my lack of time.
- I can't guarantee future time investment on these.  They are good 
enough at this point that they will sink much lower on my priority list 
as I move on to other parts of my project.


I would offer deimos inclusion, though I am not sure what the 
requirements are.  I know I have a good list of caveats there, so this 
only makes sense if deimos accepts things on a "good enough for now; 
patches accepted" kind of basis.