On Wed, 05 Mar 2014 20:58:25 GMT, Konstantinos Margaritis wrote:

I think it is most simple an generic thing to do. Just run dub build on a source and then copy resulting binary and any extra files (man pages, modules, etc) to package. Exact placement in resulting file system does not have any common standard. For example, Jordi (maintainer of http://d-apt.sourceforge.net/) uses /usr/include/dmd as base for all imports and I have chosen common /usr/include/dlang/{dmd,ldc,gdc,whatever} for Arch Linux. I think you should actually have best judgement being Debian developer :)

The previous maintainer chose /usr/include/d/ (and /usr/include/d/ldc for ldc-specific stuff), and this is what gdc also uses (it's put in /usr/include/d/4.8), so for now I'll also continue using this, but I'm not really in favour or against it, if D community says otherwise, I'd be happy to change it.

I don't think there is any sort of community standard for this sort of things. If Debian/Ubuntu users will have issues with your choice they will surely let you know ;) I have chosen "dlang" over "d" simply because it is more grep'able.

dub does not have a make install alternative so it is completely up to package to chose exact file system placement.

Lot of dub packages are source libraries though (including vibe.d) - it is enough to just copy necessary module and define dependencies to get a usable package. Example of dub-free packaging I do for vibe.d in Arch : https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/vibed/PKGBUILD (a bit outdated, oops!)

Ok, I think I understand it better now, but Debian uses a more fine-grained approach when it comes to language bindings for existing libraries (eg. libevent/openssl). I'll have to provide openssl-dlang or openssl-d (not sure which is the best name, I'll probably go for the former as it's more easy to search for), same for libevent-dlang, etc.

Another option can be to use "deimos-openssl" naming as such bindings are usually part of Deimos project : https://github.com/D-Programming-Deimos

So will it be enough to just copy ~/.dub/packages/openssl-master/deimos/openssl/* to /usr/include/d/openssl and it would be detected? And what about the stuff in the C directory, is it just duplication of the original C headers (from first glance it looks like it, but better make sure).

You will also need to make sure that ldc2.conf / dmd.conf you package with compiler have those import paths included (https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/ldc/ldc2.conf) and that relative module paths match fully qualified names of modules. If module has fully qualified name "deimos.aaa.bbb" then it has to be available via relative path ./deimos/aaa/bbb.d from one of listed base import paths (-I).

One scheme I personally find most convenient for system-wide installation is to have file system layout like this:

/usr/include/dlang/dmd
/usr/include/dlang/ldc
/usr/include/dlang/common

..so that one can put "-I/usr/include/dlang/dmd -I/usr/include/dlang/common" for dmd.conf and "-I/usr/include/dlang/ldc -I/usr/include/dlang/common" for ldc2.conf

Then source libraries that work for all compilers can be installed to "common" subdir and compiler-tweaked ones (like standard library) - to compiler-specific subdir, without any additional modification of .conf file.

gdc is a bit special though, as it may be required to conform gcc path/naming scheme once included in gcc upstream. Right now I package it in same way as ldc/dmd but probably will be forced to change it at that point.

I'd love to read your opinion about desired scheme by the way ;)

Thanks for all the help, the D community so far has been one of the friendlist I've encountered :)
I'll start with openssl-dlang and libevent-dlang and see if it works and makes building of dub and vibe.d possible and I'll post progress here.

Looking forward to it ;)