Get DUB fixed so one can actually build this around it about linedubbed HOT 5 CLOSED

Update

Thanks to the current work-around this is no longer a problem.
Unfortunately, it seems there's no way to tell DUB build but not link but build dependencies.
Investigating...

from linedubbed.

Possible solution: using DUB as library
Downside: DUB is a heavy dependency

from linedubbed.

DUB as library

Troubles

Unfortunately, it's necessary to link DUB's networking module because of dlang/dub#1558.

Benefits

• Nevertheless, dlang/dub#1556 is circumvented and dlang/dub#1557 is not a problem anymore ☺️
• Packages with targetType set to sourceLibrary can be built now (worked with the previous workaround, too).
• Packages with lib dependencies aren't a problem anymore either. Guess why: the linker is simply not called.

from linedubbed.

Since I've already turned this issue in a diary:

• The compile function (invoke) is pretty dumb and only extracts the compiler path + dflags. Whatever one passes, only those two fields matter.
• One'll need to fill the dflags array oneself by calling the corresponding functions
• There's no checking - if one doesn't do so. DUB will generate a faulty receipe and execute it. Well, if your compiler's frontend is pre-2.066, the script will be empty and will succeed (because it does nothing). Otherwise -vcolumns will be the whole receipe (creates a neat /bin/sh: 1: : Permission denied build log).
• As it seems (please correct me if I'm wrong (well, nobody will ever read this, though)), there's no high-level library entry point that allows to control the lower level parts of the build process - at least without some bigger hacking. For example, because of that one has to call the dependency resolution functions of DUB oneself.
• Everything turns out to get more and more complicated.

from linedubbed.

project abandoned

from linedubbed.