On Sunday, 19 June 2016 at 18:33:36 UTC, moe wrote:
On Sunday, 19 June 2016 at 18:00:07 UTC, Mike Parker wrote:
On Sunday, 19 June 2016 at 17:33:43 UTC, moe wrote:
Unfortunatelly I still don't get it. I would like to have an
independant project "dbar". The created lib is then used in
another project "dfoo". Assuming that "dfoo" has no access to
"dbar" other than the .lib file.
You can't do it with only the lib file. You *need* the source
file too for the import statement. As I explained, the lib
file is used by the linker, not the compiler. The compiler
needs the source file.
My folder structure is like this:
-dtest
--dbar
----source\barlib.d
----dub.json
This project creates a dbar.lib file which seams to work.
-dtest
--dfoo
----lib\dbar.d // copied from the dbar project
----source\app.d
----dub.json
You don't need to copy dbar to the lib directory in this case.
This project would use the dbar.lib but should otherwise not
have access to the dbar project. Basically simulating, that
someone else made a dbar project to which I would not have
access other than using the dbar.lib. How do I have to
configure the dub.json file for this to work?
One of two things would happen:
1) They would register the project with he dub registry, then
you add a dependency to a specific version the library. Dub
would then download the necessary files for you and ensure
that everything you need is passed to the compiler when
building your project.
2) They would provide some other means for you to get the
source and the library. Then you would need to manually
configure your dub.json to pass the import path to the
compiler and link with the library.
I have tried a variety of configurations for the dub.json. At
this point it feels like a bad guessing game. That is no way
to deveop anything. I need to figure out how to properly
setup the dub.json but I don't seam to find the answer
online. "http://code.dlang.org/package-format?lang=json";
isn't very helpful.
All the information you need is there on that page.
I have meanwhile adjusted my dtest/dfoo/dub.json to this:
"dependencies": {
"dbar": "~master"
}
This gives me the error: "Root package dfoo references
unknown package dear"
As I explained above, you need a path attribute for the
dependency in this case since it is on your local file system
and not in the registry. The documentation link I gave you
explains how to to this. Try this:
"dependencies": {
"dbar": {"path": "../dbar"}
}
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.
Thanks for your help!
Sure, you can just have a file with "extern" functions that tells
the compiler that the source for those functions isn't available
at compile time, but that later on when you link the library, the
linker will find those function definitions in the .lib file (I'm
not a Windows expert, but from my understanding .DLLs are a
different ball game, and have to be loaded and called with
special functions in your app.)
In your example, in your "dfoo.d", you can declare the functions
from the dbar.lib inside as "extern myfunction();" and the
compiler will say, "OK, myfunction() isn't defined here, so we'll
let the linker sort it out." If you try and compile without
telling it about dbar.lib, you'll get errors like "undefined
reference to myfunction()...".
When you see that somebody wrote a "binding" in D for a library
like OpenGL, etc., this is what they are providing, a .d file
filled with "extern" definitions and maybe some glue code to
convert D types into C types if the .lib file is a C library.
APIs generally work the same way. Library writers will provide a
.h header file that doesn't expose any of their closed source,
but gives users of the library the definitions of the functions
they need to use it's functions.
I hope this helps!
-Jon
