Proof of concept WASM-build of OR-Tools

[kjart...@gmail.com]

Hi!

If anyone is interested there is a fork with an experimental/poc WASM-build of OR-Tools: 

https://github.com/kjartanm/wasm-or-tools

Here is a small example on how to use it, based on one of the sudoku-examples in the contrib-section: https://github.com/kjartanm/sudoku-solver

Demo: https://sudoku-solver.krmuller.workers.dev/

Cheers!

Kjartan

[Mizux Dev]

Hi,
Thanks for this "experimental" PoC !

ps: I re-open the https://github.com/google/or-tools/issues/1670 but currently it is not scheduled for the foreseeable future (i.e. just keep it in the backlog)

Few comments for myself (and sorry, I should have done this feedback  20 days ago when you reply in the issue):

* Build on top of stable branch (v7.8)
https://github.com/kjartanm/wasm-or-tools/commits/stable

* Basically use the CMake based build with an emscripten CMAKE_TOOLCHAIN_FILE -> GOOD
ed: While we still not support cmake toolchain files (i.e. not tested and out of our current scope), it is the way to go to support Android NDK and emscripten in the near future..

So any clean patch (i.e. without breaking change) to ease this future usage will be reviewed and integrated if possible !

* Have some dirty hack to "fix" dependencies (glog and protobuf)
https://github.com/kjartanm/wasm-or-tools/commit/ef4b4fadea2c9550c0e81890490d844281ef65c7 

note: For Glog why did we need to use "HAVE_SYMBOLIZE 0" ? and the hack of raw_looging -> provide a clean patch to glog to better support toolchain and/or emscripten target should be better IMHO...
note: For Protobuf, it  should be better to check for CMAKE_CROSSCOMPILING and in this case disable the build of the protoc binary during the fetch_content() (i.e. set protobuf_BUILD_PROTOC_BINARIES=OFF when CMAKE_CROSSCOMPILING is true using generator expression ?) AND build an HOST version instead...

Then we can replace the protobuf::protoc by a host_protoc alias target etc... 

* According to the emscripten doc:

> The preprocessor define __EMSCRIPTEN__ is always defined when compiling programs with Emscripten.

ref: https://emscripten.org/docs/compiling/Building-Projects.html#detecting-emscripten-in-preprocessor

So it should be better to properly fix the code by checking this define instead of this hack ;)
e.g. https://github.com/kjartanm/wasm-or-tools/commit/17a87e1e582af581eb191609effe8363ee91c920#diff-afde8dfcb72625759b3232fdcf38f378L164-L166

* Using make_third_party, i.e. the Make based build, to retrieve all dependencies headers is not a "clean" CMake way to say the least ;)

Also I don't deeply understand why you should do it...

note: Our goal is to replace (i.e. remove) the Makefile based build by the CMake based build...

* Instead of modifying the default value of few CMake options you should pass it in your call to CMake.
i.e. in cmake-build.sh:

```diff

-    cmake -DCMAKE_TOOLCHAIN_FILE=${EMSCRIPTEN_CMAKE_PATH} ..

+   cmake -DCMAKE_TOOLCHAIN_FILE=${EMSCRIPTEN_CMAKE_PATH} -DBUILD_DEPS=ON -DBUILD_SAMPLES=OFF -DBUILD_EXAMPLES=OFF -DBUILD_TESTING=OFF ..

```

ref: https://github.com/kjartanm/wasm-or-tools/commit/ed4d8709b2a3dcc023a611b09844259b76edfa28

* wasn-build.sh should be refactored as a CMake file using a function and you shouldn't have to list by hand all dependent libraries of ortools (out of sync and should be already provided by the target attribute)

ref: https://github.com/kjartanm/wasm-or-tools/blob/17a87e1e582af581eb191609effe8363ee91c920/wasm-build.sh#L19-L87

note: need to check if there is already an "emscripten" CMake module providing this kind of tools (i.e. wrapper function for "emcc" and "emscripten") on the internet...

[kjart...@gmail.com]

Hi!

Thanks for your thorough response! As you probably already have realized, I'm a noob on C++ CMAKE stuff, so your feedback is very much appreciated. I didn't really think I would be able create a functioning WASM-build, so I just chopped away on the obstacles without any finesse :D

Using __EMSCRIPTEN__ will definitely help to clean up the fork. As using cmake options

The reason I used make third_party, was that I expected to find both 'lib' and 'include' in the output so that I could treat the output as a distributable for my emcc-build of the PoC-example in the wasm-build.sh. This is both due to my limited CMAKE skills, and also because when hitting an obstacle I had to start the build all over again, an that was very time consuming. So it was easier to test the examples with a functioning build of the dependencies, than to include full build every time I did a change. So then I used  the include from the make third_party-build since i didn't find any include from the cmake-build. I'm sure there is a less hackish way to to that :D

It seems that Glog will have full wasm-support with the next release, so that will hopefully work out of the box soon. With protobuf, your suggestion sounds like a good idea, but there I need to up my cmake-skills to see how that could be done.

[kjart...@gmail.com]

Hi again!

Regarding HAVE_SYMBOLIZE 0.

The build breaks in symbolize.cc, even if it passes the HAVE_SYMBOLIZE test in CMakeLists.

Kjartan

[Mark]

I've recently been looking at the possibility of including an ORTools model in an android app and this seems to be the most recent discussion.

From what I'm seeing (https://github.com/google/or-tools/issues/1670) it looks like you're currently targeting emscripten for wasm compilation in release 9.1.

From what Mizux said above, it sounds like the bottleneck for both wasm and Android NDK is the cmake build.

Is the plan to only allow the native C++ API on android, or will the Java bindings from swig (and perhaps thus Kotlin) also still be valid?

Just trying to get some sense of what integrating ORTools into an android app will probably involve on the user's part.