On 10/16/2011 8:10 PM, Vladimir Panteleev wrote:
1) Will these be distributed with DMD? The bar to generate D import modules from C headers isn't much higher than having to find and download headers from the Internet.
I was thinking, no at this time. I suspect it may grow to be quite large, and would become rather onerous. I also don't want to tie it to the DMD release cycle.
2) This isn't too different to already existing projects. The bindings project on dsource ( http://dsource.org/projects/bindings ) already has bindings for various libraries. I can't say much about the project guidelines, though.
The bindings project is a great resource, though it seems a little disorganized. We've had great success with github, meaning it seems to be very good at encouraging community participation.
3) You suggest to place each library in its own directory, with C and D headers as subdirectories. This means that the user will still need to edit the import search path when using a new library.
Yes.
Is it realistic to put all D files in the same directory? (Perhaps do this only for libraries for which we don't expect name collisions?)
Hmm, you're right. Perhaps openssl.whatever.
4) "Every effort will be made to avoid needing any D specific binary files." - What about import libraries?
What do you mean by import libraries? Do you mean Windows DLL import libraries? Those would be supplied by whoever supplied the C library. D can access those directly.
CAPI should be interface source code only library; the D equivalent of #include.
