www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Dub project with .lib/.dlls for static binding

reply jmh530 <john.michael.hall gmail.com> writes:
I'm not sure this makes much sense, but it's something that's 
been rolling around in my head the past 2-3 days.

One of the great things about Python's Anaconda is that you just 
download one file, install and it just works. In D, dub offers 
comparable functionality as conda, which is very helpful. Usually 
it doesn't take much to get up and running with dub. This is 
especially true with projects that only use D code. However, 
things can get a little more complicated when a dub project in 
turn depends on some C library or something. I think this 
particularly applies to static binding. In my experience, it's 
usually far easier to deal with these sorts of issues with Linux 
than Windows. This additional difficulty likely would make it 
less likely that some Windows user would switch from Python to D.

To reduce this difficulty, given some C library that already has 
D bindings available, I would start a separate dub project that 
just includes the .lib or .dlls necessary for Windows. Then, a 
wrapper (or more generally, any library that uses the bindings) 
could then have a dub sub-configuration such that Windows 
requires the previous dub project and uses it for dll/libs (also 
including a switch that would allow the user to put the path to 
them manually).

This way the user could download the D binding themselves and do 
things manually, or they could use the wrapper and have a "just 
works" experience on Windows (with the option for manual 
customization).

Am I making sense here? Anything I haven't thought of?
Sep 13 2017
parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 13 September 2017 at 19:55:03 UTC, jmh530 wrote:
 I'm not sure this makes much sense, but it's something that's 
 been rolling around in my head the past 2-3 days.

 One of the great things about Python's Anaconda is that you 
 just download one file, install and it just works. In D, dub 
 offers comparable functionality as conda, which is very 
 helpful. Usually it doesn't take much to get up and running 
 with dub. This is especially true with projects that only use D 
 code. However, things can get a little more complicated when a 
 dub project in turn depends on some C library or something. I 
 think this particularly applies to static binding. In my 
 experience, it's usually far easier to deal with these sorts of 
 issues with Linux than Windows. This additional difficulty 
 likely would make it less likely that some Windows user would 
 switch from Python to D.

 To reduce this difficulty, given some C library that already 
 has D bindings available, I would start a separate dub project 
 that just includes the .lib or .dlls necessary for Windows. 
 Then, a wrapper (or more generally, any library that uses the 
 bindings) could then have a dub sub-configuration such that 
 Windows requires the previous dub project and uses it for 
 dll/libs (also including a switch that would allow the user to 
 put the path to them manually).
 This way the user could download the D binding themselves and 
 do things manually, or they could use the wrapper and have a 
 "just works" experience on Windows (with the option for manual 
 customization).

 Am I making sense here? Anything I haven't thought of?
No you are not, it's just currently a bit painful to do manually due to e.g. missing support for git submodules. However, some projects already do this: Windows: https://github.com/ariovistus/pyd/blob/master/dub.json And for Linux it's even possible to compile small dependencies on the fly: https://github.com/dlang-community/drepl/pull/63 Imho if the library is small, compiling it (or using prebuilt for Windows), should be the default behavior because it's a very pleasant user experience
Sep 13 2017
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 13 September 2017 at 22:50:54 UTC, Seb wrote:
 No you are not, it's just currently a bit painful to do 
 manually due to e.g. missing support for git submodules.
 However, some projects already do this:

 Windows: https://github.com/ariovistus/pyd/blob/master/dub.json
I was not aware that pyd does that, but it is very similar to what I'm saying. The difference would be to put the .lib files in a separate dub project. Instead of having the dub.json pointing to the location of the lib files within the pyd project, there would be a dependency on the lib project and a link to the files within that. I suppose there is no real reason why there needs to be a wrapper. This behavior can get added to D bindings. Regardless, I suppose the main motivation of not putting it in the bindings is that if someone is using the library on Linux, then they don't need to download any of the Windows lib files. The only change would be a small change to the dub.json to account for the different Windows behavior.
 And for Linux it's even possible to compile small dependencies 
 on the fly:

 https://github.com/dlang-community/drepl/pull/63
I'm specifically interested in good support for Windows.
 Imho if the library is small, compiling it (or using prebuilt 
 for Windows), should be the default behavior because it's a 
 very pleasant user experience
I'm 100% pro-"very pleasant user experience." The problem is that it usually isn't on Windows in this case. You often have to go find the library yourself and existing pre-built ones may not be in the right format (How were they compiled? MinGW or MSVC? What linker? Etc) so you have to go build it yourself. Deimos projects, for instance, are just C headers and D bindings. No .lib files.
Sep 13 2017