Support targetType 'wasm'

[lempiji]

WebAssembly is supported with LDC 1.11.0.
If wasm is added to the targetType, I think that development becomes easier.

  "targetType": "wasm"

I wrote such a code. How about that?

[AntonMeep]

I don't think that it should be implemented as targetType. Target type defines what will be produced: an executable or a library.

It'd be better to add --arch=wasm32 option instead. After all, D programs are cross-platform and --arch is meant to force a different architecture (in this example, wasm).

[PetarKirov]

I think the end goal of having full support for cross-compilation should be achieved as follows:

1. Extend the platform specification from <os>-<architecture>-<compiler> to support specifying a full target triple: <arch><sub>-<vendor>-<sys>-<abi>-<compiler>
2. For dub build --arch=... the architecture parameter should also accept a full target triple
   • For wasm, so far there are two important target triples:
     • dub build --arch=wasm32-unknown-unknown-wasm
     • dub build --arch=wasm64-unknown-unknown-wasm
   • For Windows:
     • dub build --arch=i686-pc-windows-gnu (COFF object format, based on MinGW)
     • dub build --arch=x86_64-pc-windows-gnu (COFF object format, based on MinGW-w64)
     • dub build --arch=i686-pc-windows-msvc (COFF object format, based on MS Visual C++)
     • dub build --arch=x86_64-pc-windows-msvc (COFF object format, based on MS Visual C++)
     • dub build --arch=i686-pc-windows-dmc (OMF object format, based on DigitalMars C++)
   • For Android that may be:
     • dub build --arch=arm-linux-androideabi
     • dub build --arch=armv7-none-linux-android
     • dub build --arch=aarch64-linux-android
     • dub build --arch=i686-linux-android
   • Or for Alpine Linux:
     • dub build --arch=x86_64-alpine-linux-musl
3. If a package has only configurations which are constraint by platform, dub should infer the set of possible platforms that the package or its dependents can be built for. For example:
   • Package R (root) depends on package A and package B. Package A is buildable for Posix x86_64 and package B is buildable for Linux i386, x86_64 and AArach64. While package A could be build for x86_64 Linux, FreeBSD and macOS, the package R, could be built only for Linux x86_64.
   • If a library L's (direct or indirect) dependency is buildable only for wasm32 and an executable E which can target only wasm64 depends on L, it follows that the platform constraint could never be satisfied, so dub build E must fail.
4. Allow specifying platform toolchains like a linux x86 host to aarch64-linux gcc. All the information that one may need to specify to the ldc-build-runtime tool and the paths to cross-compiled druntime and phobos.
5. Allow specifying runners/emulators like QEMU for dub run / dub test

[WebFreak001]

@ZombineDev imo vendor doesn't make any sense in there. What could it possibly add that sys and abi not already describe?

[PetarKirov]

@WebFreak001 the idea is to adapt a standard, well-known format and not invent our own.

The vendor needs to be specified only if there’s a relevant change, for instance between PC and Apple. Most of the time it can be omitted (and Unknown) will be assumed, which sets the defaults for the specified architecture. The system name is generally the OS (linux, darwin), but could be special like the bare-metal “none”.

[WebFreak001]

@ZombineDev can we use something else than these triples then? Well if dub had a way to list all possible triple combinations it would be ok but otherwise it's just even worse than when using clang then. I mean otherwise even for your example triple combinations it would be basically impossible to find them out without looking them up somewhere online. That's like such a huge pain with these triples which is why I don't like them.

[s-ludwig]

@WebFreak001 I think thís is a bit beside the point. If you want to cross compile to such a platform, you need to know the triple, no matter what the format is. On the other hand, for native compilation the existing architecture flag is going to stay, so the additional complexity won't show up.

Of course, we could define our own identifiers that map to such triples to simplify that, but then we could also just put up a documentation page with common triples. Also, the list would grow to a point where it will be just as hard to find out the right identifier for a given target system.

[WebFreak001]

hm ok I can see advantages in regards with LDC compatibility. On DMD I guess it could be somewhat interpreted for some settings.

But if we have these triples how is dub going to decide on the build steps then? Especially linking will require different tools and different arguments potentially for every triple.

I think there should definitely be some documentation page with common triples and some custom identifiers mapping to some.

Also about the suggested triples: x86_64-pc-windows-gnu what would happen if I didn't specify pc here? (as you also didn't specify it for the android ones) There would need to be basically default values for everything based on other parameters. Also the range of valid parameters would basically be depending on all other parameters. Like with windows other valid systems could be xbox one or hololens but they clearly don't apply on other systems.

Also I think having unknown (or rather the undefined behaviour the name implies) would be bad design as it could change any release.

[PetarKirov]

1. Yes for DMD we'll interpret the target triple initially, until we add -mtriple support to dmd as well.

2. The advantage is for compatability with C toolchain, which LDC and GDC already support.

3. But if we have these triples how is dub going to decide on the build steps then? Especially linking will require different tools and different arguments potentially for every triple

Good question. It depends on the compiler used. LDC's config file supports specifying details like this per target triple in its configuration file. So in the most basic case Dub will call LDC and LDC will handle the rest. AFAIU, for GDC you will have a cross-compiler for each target platform installed in a different folder.
On Dub's side we may want to support specifying per target triple toolchain options (assembler, linker, C compiler, D compiler, system libs to link, etc.) to support more advanced use cases.

4. I think there should definitely be some documentation page with common triples and some custom identifiers mapping to some.

Yes, definitely.

5. Also about the suggested triples

Just to clarify: I didn't invent any of those triples (except for the i686-pc-windows-dmc one?). They're what's already established in the real world today.

x86_64-pc-windows-gnu what would happen if I didn't specify pc here? (as you also didn't specify it for the android ones) There would need to be basically default values for everything based on other parameters. Also the range of valid parameters would basically be depending on all other parameters. Like with windows other valid systems could be xbox one or hololens but they clearly don't apply on other systems.

For vendor: as mentioned before most of the time you probably wouldn't need to specify it as the compiler will infer the right thing from the OS field. But it's there for those who might need it. Not specifying the vendor or typing unknown explicitly should always be safe as it means the compiler will either determine the right thing automatically, or make as few assumptions as possible when the OS is not specified - useful for platform bring up and/or bare metal development.
As for the set of valid combination of values, it's up for the compiler to decide / support.

[Geod24]

Superseeded by #1755 ?

[kinke]

Yes;

dub build --arch=wasm32-unknown-unknown-wasm

that works now with master.

[lempiji]

I can build to the wasm, so I close this PR.
It seems that it may still fail with Windows, so I will report it separately.