RejectedSoftware Forums

On Fri, 10 Oct 2014 07:32:22 GMT, Martin Nowak wrote:

This might be a good starting point.
https://github.com/D-Programming-Language/dub/pull/431

Deimos packages are always header only libraries (source library as target type).

The Windows lib files should be distributed separately, so that people can install them in their LIB/BIN folder. In the dub package you then just add a library field, so that dub knows what to link.

Hi,

thanks.

I thought that libraries are distributed as a part of dub packages. I understand the advantages to using system-wide libraries, however, I can easily imagine a situation when I would want to use different lib (e.g., when deimos bindings are for some incompatible version). Also getting own versions of libraries can sometimes be a pain in the ass (especially on Windows), so the ability to distribute also these libraries would be good. Not to mention that windows do not have IMHO a standard library folder (aside from system32 and SxS).

Is it possible to somehow do it with dub?

On Fri, 10 Oct 2014 11:52:16 GMT, Martin Nowak wrote:

Is it possible to somehow do it with dub?

Well vibe.d does it with openssl https://github.com/rejectedsoftware/vibe.d. You would have add linker flags to your libssh package. Not sure if the pathes work out.

Yes, that's what I had in mind. Should have checked it first...
However, I still have a problem (sort of). In my project I want to use vibe.d alongside libssh2. If I prepare dub package for libssh2, each will have its own version of openssl. While .lib files could be kept separate, there can be only one .dll (unless I give it some funny name to distinguish it).

It would be best to be able to share these libraries across dub packages, but I guess that is currently impossible and very improbable in the future.

Thoughts?

Am 10.10.2014 14:14, schrieb Drasha:

On Fri, 10 Oct 2014 11:52:16 GMT, Martin Nowak wrote:

Is it possible to somehow do it with dub?

Well vibe.d does it with openssl https://github.com/rejectedsoftware/vibe.d. You would have add linker flags to your libssh package. Not sure if the pathes work out.

Yes, that's what I had in mind. Should have checked it first...
However, I still have a problem (sort of). In my project I want to use vibe.d alongside libssh2. If I prepare dub package for libssh2, each will have its own version of openssl. While .lib files could be kept separate, there can be only one .dll (unless I give it some funny name to distinguish it).

It would be best to be able to share these libraries across dub packages, but I guess that is currently impossible and very improbable in the future.

Thoughts?

Is it necessary to actually have two versions? Unless I'm mistaken, that
would always cause the linker to throw errors due to duplicate symbols,
except if the main application would dlopen its version of OpenSSL
instead of statically linking against it.

But the OpenSSL API is very stable, so it shouldn't matter much if a
newer version is used for either the application, or for libssh2.
Ideally, I would imagine to have two packages, one for OpenSSL and one
for libssh2, where each provides its part of the equation (linker flags
on Posix and linker flags + binaries on Windows). The libssh2 package
would then simply depend on the OpenSSL package to get its version of
the OpenSSL library.

Am 20.10.2014 12:11, schrieb Drasha:

On Mon, 20 Oct 2014 09:38:55 +0200, Sönke Ludwig wrote:

Is it necessary to actually have two versions? Unless I'm mistaken, that
would always cause the linker to throw errors due to duplicate symbols,
except if the main application would dlopen its version of OpenSSL
instead of statically linking against it.

But the OpenSSL API is very stable, so it shouldn't matter much if a
newer version is used for either the application, or for libssh2.
Ideally, I would imagine to have two packages, one for OpenSSL and one
for libssh2, where each provides its part of the equation (linker flags
on Posix and linker flags + binaries on Windows). The libssh2 package
would then simply depend on the OpenSSL package to get its version of
the OpenSSL library.

Yep, I would consider this to be the ideal situation as well. However, I have not find a way to tell dub to add import libraries from another package to my project.

How complicated would it be to add this to dub? I imagine that all that would be needed is to enable adding other dub projects to sourcePaths (e.g., something like sourcePaths : ["!openssl"] with "!" meaning that is not a path on a filesystem, but a directory of a particular package).

It should be enough to add in this case "openssl" as a dependency to
"libssh2". All external link libraries will be linked to the final
binary (shared library or executable). They same should be true for
*.lib files passed to "sourceFiles", but I didn't verify this.