multiple wasm backends (aka interpreter)

[wanderingbort]

link in the Binaryen interpreter from the version installed as part of our build script into the wasm interface and allow hot swapping between that and the jitter (currently defaulting to the jitter but perhaps not for long?)

Note, this creates a code link to binaryen's 1.37.x release as the embedding API has changed at some point after that.

[spoonincode]

this creates a code link to binaryen's 1.37.x

Is there a way we can enforce that somehow here? I know that will require changes to the FindBinaryen.cmake

[wanderingbort]

sadly no, there seems to be no header level or file level build stamping. If we want to assume that binaryen's directory is a git repro we could look at the tag, however our standard install script does not survive the git repo

[wanderingbort]

@heifner Travis is failing because the OCI repo has binary versions of binaryen but not the src directory needed

@ericiles It looks like Jenkins is failing because the previous version of the installer doesn't survive the parts of binaryen we need (the new installer does)

[spoonincode]

Since we're basically dipping our fingers in to what is considered private source -- not the publicly defined API for the library -- why not just bring the source in as a submodule? It's bizarre and confusing for us to still depend on the external source tree of binaryen after doing a make install of binaryen. This isn't how it works for any other library.

[heifner]

We have decided to kill Travis build since we now have Jenkins in place.

[wanderingbort]

So, the new Jenkins error, reproducible locally on Ubuntu 16.04 seems to have something to do with compiling binaryen as a dependency with the system compiler (aka GCC 5.4 on ubuntu 16.04) and linking those libraries to our executable compiled with ClangX. Using GCC 7.x shows no problem and using Clang to build binaryen also shows no problem.

The net result is that I will be passing the buck to @spoonincode (sorry) to link Binaryen is a a submodule instead of a build dependency. This is probably more apropos as we were not using the released libraries/headers as is and were techincally linking against internal libraries.

Marking this PR as in progress as a result.

[brianjohnson5972]

At some point, we want to change this to 0 (or some invalid value??), I had put 11 just as a place holder if the code to accumulate the count was added to apply_context.

[asiniscalchi]

Looking to the FindBinaryen you coded it seems you are trying to add the targets generated by Binaryen build using a Find*.cmake syntax.
Actually it is very confusing cause Find*.cmake paradigm is used to find installed packages (headers, binaries, and libs) not internal libraries into a building tree.
I suggest to add the Binaryen source into EOS source (submodule + add_subdirectory) or use cmake paradigm: ExternalProject

[spoonincode]

@asiniscalchi yes that's exactly what we're going to do; binaryen source (from eosio fork) will be included as submodule

[spoonincode]

Be advised -- there is still much work to be done to clean this up. And WAVM is still the runtime used. But I think we can merge this now and clean up via smaller PRs based on master.