Should we create `em` wrapper scripts for other llvm tools (such as llvm-dwp and llvm-nm)?

[sbc100]

This is maybe an emsdk issues since other users of emscripten probably have such tools in their PATH already.

It certainly seems like users would want access to other llvm tools such as llvm-nm, llvm-dwp, etc, but emsdk does not add the llvm tools to the PATH by default.

We could have simple no-op wrappers in the emscripten directory called em-nm em-dwp? Or we could just ensure the llvm tools are in the PATH? We do have a couple of existing no-op wrappers emar and emranlib, but historically they were requires since we had slightly different behaviour to upstream. They are still around but mostly for legacy reasons.

Reasons to use wrappers scripts:

1. Avoids putting tip-of-tree llvm tools in users path (avoids shadowing system tools)
2. Ensures the correctly-configured version of llvm tool is used, no just the one in the PATH.
3. Consistency with emcc and emar

Reasons to avoid wrapper scripts:

1. Extra overhead per call. Runs a shell and a python process.
2. They don't actually add any actual functionality
3. Could lead to confusion if folks think these are actually different to upstream tools in some way (More than one way to do that same thing).

[sbc100]

Also, I wonder if we should call this tools em-foo rather than emfoo to match how cross compilers and other folks normally name tools:

e.g. llvm-ar is not llvmar and arm-linux-gxx is not armlinuxgcc.

[sbc100]

@kripken @dschuff

[sbc100]

@walkingeyerobot

[curiousdannii]

Could there be a generic wrapper called em which takes as its first argument the tool to run like em llvm-dwp?

[sbc100]

Interesting idea! Certainly worth considering.

[kripken]

+1 for emdwp for now.

I agree that em- as a prefix makes more sense, but am not sure it's worth changing?

If a generic em wrapper can work that sounds very cool!