RejectedSoftware Forums

Sign up

Pages: 1 2

Re: (re-)package dub packages in Debian

On Tue, 11 Mar 2014 16:09:35 GMT, Konstantinos Margaritis wrote:

On Sun, 09 Mar 2014 13:10:02 GMT, Dicebot wrote:

What kind of linking errors? Application written using vibe.d need to be linked to libevent and openssl. dub takes care of it automatically but for stand-alone package I have written this simple runner script: https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/vibed/viberun

Linking errors like this:

http://dpaste.com/hold/1715523/

I see the problem. You compile only new module itself, not any of those it imports. This is why my script uses rdmd helper - it goes through all imported modules and compiles them too.
With ldc it will be rdmd --compiler=ldmd. rdmd is not the same thing as dmd, it is extra tool that will work with any compiler having conformant CLI (https://github.com/D-Programming-Language/tools/blob/master/rdmd.d)

This can also be partially fixed by providing pre-built static library but that is not a good approach because:
1) programmer can't use "-version" switches to fine tune his app anymore
2) emitting of template instances is rather devious right now

vibe.d itself can be pre-built as a static library to speed up compilation of user code but it is not necessary

It may be the case that I'll have to provide a static library then if ldc needs it. As I understand it, dmd backend is using a proprietary license and I can't include it in Debian, I hope I'm wrong there :-/

rdmd --compiler=ldmd should help. However you will need to package rdmd for that (https://github.com/D-Programming-Language/tools/blob/v2.064.2/rdmd.d). Should be trivial as it is one module binary.

You concerns about dmd backend are valid. This licensing issue is for historical reason and Walter can't change it unfortunately. He always grants re-distribution permission when asked but as far as I know Debian has strong policies about it and such compromise won't be acceptable. But ldc should be good enough as far as I am familiar with its current capabilities.

Re: (re-)package dub packages in Debian

On Tue, 11 Mar 2014 18:56:32 GMT, Dicebot wrote:

I see the problem. You compile only new module itself, not any of those it imports. This is why my script uses rdmd helper - it goes through all imported modules and compiles them too.
With ldc it will be rdmd --compiler=ldmd. rdmd is not the same thing as dmd, it is extra tool that will work with any compiler having conformant CLI (https://github.com/D-Programming-Language/tools/blob/master/rdmd.d)

Ah, I see, didn't know that, so that's the missing wheel in the gearbox :)

This can also be partially fixed by providing pre-built static library but that is not a good approach because:
1) programmer can't use "-version" switches to fine tune his app anymore
2) emitting of template instances is rather devious right now

Yes, I understand, I'll go for the source-only packages for now, it makes things actually easier to do, plus it's nice to the archive, better to have arch:all packages instead of many port-specific ones :)

rdmd --compiler=ldmd should help. However you will need to package rdmd for that (https://github.com/D-Programming-Language/tools/blob/v2.064.2/rdmd.d). Should be trivial as it is one module binary.

I see, would it make sense to build the whole tools as a single package (or maybe as a single source package with many smaller binary packages)? Are the rest of the tools useful and something that D developers would be interested in having?

You concerns about dmd backend are valid. This licensing issue is for historical reason and Walter can't change it unfortunately. He always grants re-distribution permission when asked but as far as I know Debian has strong policies about it and such compromise won't be acceptable. But ldc should be good enough as far as I am familiar with its current capabilities.

Ok, I understand, so far my (small and probably trivial) tests with ldc were successful, however gdc wasn't as much.

Thanks a lot for your kind help!

Re: (re-)package dub packages in Debian

On Tue, 11 Mar 2014 22:22:07 GMT, Konstantinos Margaritis wrote:

I see, would it make sense to build the whole tools as a single package (or maybe as a single source package with many smaller binary packages)? Are the rest of the tools useful and something that D developers would be interested in having?

Don't know, to be honest. There are 2 extremely useful and widely used tools in that repo - rdmd and dustmite (tool to reduce bugs to minimal test cases). Others are much less used and the fact that makefile was broken in that repo until recently does not really help. I packages those from repo that can be trivially built without makefile (https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/dtools/PKGBUILD), but mostly because of purism rather than real demand.

Pages: 1 2