Troubleshooting DUB invocations

[Dukc]

On Monday, 18 November 2019 at 19:35:13 UTC, Sebastiaan Koppe 
wrote:
> 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.
>

Yeah, definitely useful if you want to link in, say, a C-borne 
wasm
binary.

> 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`.

That was news to me - I thought everything was always being 
compiled to WASM.

>
> 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").

I have sometimes thought that perhaps a static assert isn't the 
best thing to use for unimplemented features in Phobos, precisely 
because of this issue. A @disabled function stub would serve 
better, unless I'm missing something.

>
> 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.

"ending up"? If it's like what getting Phobos to work has been 
for me, you're continuing the game, not ending up playing it ;D.

>
> 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.

Do not hurry more than you want -I already got my 
extract-dub-failure workaround working.