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!