Using .lib and .dll in D applications

[Mike Parker via Digitalmars-d-learn]

On Sunday, 19 June 2016 at 18:33:36 UTC, moe wrote:

>
> I see where I went wrong. I thought that it's possible to only 
> use the .lib file without the source code of dbar. Having 
> access to the source makes what I am trying somewhat pointless. 
> Is it otherwise possible to provide some functionality without 
> having to give away your source? I would like to put together a 
> library that I can reuse, without having to rely on the source 
> each time. Maybe a dll instead?
>
> Note: I don't have a problem with giving away my code. I just 
> want to know if it can be done. Or maybe later build a plugin 
> system where the creator of the plugin does not need the source 
> of the entire application. And in turn the app does not need to 
> be recompiled in order to use the plugin.

DLLs also have nothing to do with compilation. That's a runtime 
thing. D is not like Java, where everything you need is bundled 
in an archive and can be used at both compile time and runtime. 
It's more like C and C++, where there are very distinct formats 
in use and compile time and runtime. The compiler needs to know 
which symbols are available for you to use in your module. It can 
only get them from the source for the modules you import, not 
from any static libraries or DLLs.

D does support interface files (called 'D Interface' files, with 
a .di extension). These are stripped down versions of your source 
code that can be shipped with your binary. Instead of having full 
function implementations, you have the declarations only. This 
means that none of those functions can be inlined. And you still 
need the full implementation of any templates in the library, 
otherwise the templates can't be instantiated. .di files are more 
like C and C++ header files. You can generate them from any D 
source file by passing -H on the command line during compilation.

The primary benefit of .di files is to hide the source. Since you 
say you don't care about that, you probably shouldn't worry about 
them.

Really, if you are using DUB to manage your projects and don't 
care about hiding the source, then there's nothing to worry 
about. You can put your libraries on github or BitBucket, 
register them with the DUB registry at code.dlang.org, and then 
everyone who uses them as dependencies will have everything they 
need automatically. You could also bundle them up in zip files 
and distribute them that way. People can run dub to compile the 
libraries and then configure their project locally to find what 
they need. It isn't a problem at all.