Troubleshooting DUB invocations

[Sebastiaan Koppe]

On Wednesday, 13 November 2019 at 18:10:15 UTC, Dukc wrote:
> On Wednesday, 13 November 2019 at 15:41:01 UTC, Sebastiaan 
> Koppe wrote:
>> It has been on the back of my mind since 1.18-beta came out. I 
>> am going to reserve a little time tomorrow to work on it.
>
> Regarding that, perhaps I can save you a bit trouble if you 
> also try to get 1.19 working: if you get compile errors related 
> to SortedRange, the fix is 
> https://github.com/dlang/phobos/pull/7266.

I have had some time today to look into this. About the 
--no-as-needed:

TL;DR: add `--build-mode=allAtOnce` to the dub command.

Kinke made some changes in dub to facilitate separate linking for 
ldc. I am not aware of all the details but the major benefit is 
that it allows cross compilation with dub and ldc.

Because of the separate linking the --no-as-needed turned up. As 
far as I can see it is only needed when compiling for linux.

Which brings up the question, why linux? Aren't we compiling for 
wasm?

Well yes. But that is just the way things worked up until now, 
ldc and dub just pick the host machine.

Luckily there is the new dub `--arch` argument that can take a 
llvm triple, in our case wasm32-unknown-unknown-wasm. This causes 
dub not to add the `--no-as-needed`.

Except, that it also passes the triple upwards the dependency 
tree. Now all the dependencies of spasm get compiled targeting 
wasm. This is a good thing, except that the optional package 
which spasm depends on fails to compile with it. There is a newer 
version that fixes the configuration, but that one fails because 
of the `from.std` import idiom (it imports the std package from 
phobos which doesn't recognise wasm and fails with "Unknown OS").

In the end it is all caused by phobos and druntime not knowing 
anything about wasm. Which I am currently working on behind the 
scenes to fix.

In the meantime I am going to make a PR for the optional package 
to avoid the `from.std` idiom. Although I might end up playing 
whack-a-mole here, as there might be more dependencies that need 
a fix now.

Another workaround that you can use right now is by adding the 
`--build-mode=allAtOnce` argument to dub. It effectively gets you 
the old behaviour. It is what I am using in my CI to get it to go 
green again.