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.