2017-02-26 20:17 GMT+01:00 Andreas Tille <andr...@an3as.eu>: > [...] >> but in general I would >> strongly recommend to not use dub at all for Debian packaging. >> It has a lot of issues which make it a pain to work with in the >> context of Debian packaging, some of the issues are summarized at >> https://gist.github.com/ximion/fe6264481319dd94c8308b1ea4e8207a >> >> I did packaging with dub once, a d/rules file would look similar to >> this: >> https://anonscm.debian.org/git/pkg-packagekit/appstream-generator.git/tree/debian/rules?id=60dcc4c6e716f8ddbcf549f40bad0f5b800cb398 >> >> No package in Debian uses dub however, because it creates long-term >> maintenance pain. The much better option is to submit a patch upstream >> to build with either Automake, cmake or Meson. I strongly recommend >> Meson here, because Meson configuration is very easy to write and it's >> D support is already there (while it needs to be added to cmake with a >> lot of macros, and Automake is just annoying to use in general). >> >> Here is an example for a simple Meson build configuration for a very >> small static D library: >> https://github.com/repeatedly/mustache-d/commit/4e694202b02014871a767782606bacaf1422a3e2 > > I'd fully trust your insight here but I admit Meson is totally new to me > and crafting a Meson control file for a library without having any idea > about D is a bit over my current status of knowledge. So I either need > to use what upstream provides or ask here for help.
D is really easy to write if you know a bit of C and maybe Python or Java ^^ Writing a Meson build definition is trivial too, I can write on for this project if you want and sibmit it upstream. >> > Ah, I was looking at upstream git master which contains this dependency >> > in dub.json: >> > "dependencies": { >> > "undead": "~>1.0.6" >> > }, >> > >> >> bio/bam/bai/indexing.d(38,8): Error: module string is in file >> >> 'core/std/c/string.d' which cannot be read >> >> >> >> This seems to be critical. Do you have any hint? >> > >> > Maybe this PR would help? >> > https://github.com/biod/BioD/pull/23 >> >> Which D compiler do you use for building? LDC or GDC? I would >> recommend LDC here, since it supports the latest D runtime and >> standard library versions, while GDC is lagging behind a lot. >> The ideal solution here would be to port BioD away from using >> deprecated stuff, but I am not sure how feasible this is - would be >> nice to at least ask upstream on whether they accept patches for it. >> Otherwise, undeaD needs to be in Debian first. > > I admit I have no idea how to do this. Its the first time I see D code > at all. May be it would be even better if the Debian D team could > package BioD which I need for some other package as a pre-dependency. I'd rather not want that to happen - the D team is currently mostly me (and Markos), and packaging a library which we don't use is a bad idea. I have too many packages already and I fear I will not be able to adequately maintain them if I have too many and don't even use them. However, I could help with the packaging. I'll see whether BioD is easy to port away from std.streams (doesn't look like it unfortunately) and if not I could supply Meson build definitions to the projects. Is BioD a normal shared library? What are you doing with it? Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/