Add some sort of "wrapper" argument

[attilaolah]

Short version: it would be convenient to have a "wrapper" tool that gets executed as a prefix before cmake, make and …/configure. This is specifically to target the existing wrappers for Emscripten: emcmake, emmake and emconfigure.

---

Version 0.3.0 removes the make_commands argument from make(). This is great, as passing targets and args is much more flexible, and in general works better, however, I was (ab)using make_commands to pass my own wrapper, and thus call emmake make and emmake make install directly.

The same would be very useful for configure_make(). Currently I use a workaround where I patch in an emconfigure.sh into the source archives, which constructs the right command (emconfigure configure …) based on environment variables that I need to pass in at build time.

For CMake, there is no easy way to pass in such a wrapper, but the Emscripten CMake wrapper actually does very little other than passing in some cache entries like CMAKE_TOOLCHAIN_FILE, which sets CMAKE_MODULE_PATH, CMAKE_CROSS_COMPILING_EMULATOR, etc.

I've been trying to resist adding such a wrapper arg myself as I was instead trying to get all the right flags from Bazel, to get the regular ./configure and make produce a wasm32 build based on the CC toolchain flags alone. But it's getting harder to do that, and with the removal of make_commands from make() (which, btw, is still there in configure_make) it is quite a challenge now to pass in the right incantations to make() to get it to cross-compile properly.

[UebelAndre]

I think the solution here is to register a `` toolchain using native_tool_toolchain:
https://github.com/bazelbuild/rules_foreign_cc/blob/2407938f22aaf09e5705e726037cf61e2003b291/toolchains/native_tools/native_tools_toolchain.bzl#L32-L61

We use that here:
https://github.com/bazelbuild/rules_foreign_cc/blob/2407938f22aaf09e5705e726037cf61e2003b291/toolchains/BUILD.bazel#L33-L37
https://github.com/bazelbuild/rules_foreign_cc/blob/2407938f22aaf09e5705e726037cf61e2003b291/toolchains/BUILD.bazel#L77-L84

If you build with this toolchain, then the environment variable MAKE (#638) will be set to whatever the executable is from that toolchain.

[attilaolah]

Oh that's cool! I'll give that a try, thanks.

To be fair, I used to do that (register my own toolchain), but I did it somewhat differently: I registered a wasm-only toolchain, but I registered it only for cpu=wasm32, so I did not need to use a select() in the path attribute: I could rely on Bazel toolchain resolution.

At some point recently I abandoned that approach as it seemed it was no longer necessary, and instead I modified the args to the existing toolchains using select(). And that worked (so-so) until 0.3.0. But I'm refactoring my repo a bit now to make it 0.3.0-compatible and I'll probably go back to the custom toolchain approach again.

[attilaolah]

OK I remember now. The trouble with the custom toolchain was that it needs multiple tools, including the original toolthain tool. This is because the command that I need to run ends up being emcmake cmake instead of just cmake. Same goes for make, I need to run emmake make, but that needs the original make tool to be available, in addition to some extra tools like Python (which I build myself, using configure_make() of course :) with cfg = "exec"), and NodeJS, which I borrow from rules_nodejs.

And back then I couldn't figure out how to properly aggregate all those tools in one rule so that I can pass them to as target to native_tool_toolchain.

[attilaolah]

I looked at what those wrappers do (emmake, emcmake, etc.), and apparently all they do is set some environment variables, which Blaze already sets for the most part, and for emcmake I just set them myself, so the wrappers are not really needed.

Let's not add any more extra args then, there are many already.

And thanks for helping with this case!