Feature request: A browser-friendly version of or-tools (emscripten)

[franzen]

With web development frameworks such as Vue, React and Angular, a web-based version (WASM) of or-tools would make a big difference for us developers. The ability to solve many optimization problems directly in the browser would provide a better user experience and the opportunity to do work in the browser when offline.

Unfortunately, I'm not a star on tools like https://emscripten.org/, otherwise I would have made the first attempt myself. But can it be a simple task for someone else in this community?

Thank you for your hard work on this project!

[lperron]

As expected, you, or somebody else can try. :-) But I will not spend some time on it. I prefer the client server approach.

…

--Laurent Le ven. 25 oct. 2019 à 22:33, Nils Franzen <notifications@github.com> a écrit :

With web development frameworks such as Vue, React and Angular, a web-based version (WASM) of or-tools would make a big difference for us developers. The ability to solve many optimization problems directly in the browser would provide a better user experience and the opportunity to do work in the browser when offline. Unfortunately, I'm not a star on tools like https://emscripten.org/, otherwise I would have made the first attempt myself. But can it be a simple task for someone else in this community? Thank you for your hard work on this project! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1670?email_source=notifications&email_token=ACUPL3M3BNH2CW3WA4RVH7DQQNJYHA5CNFSM4JFI2YQKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HUPJYYQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3NRZ4K4X67RI4PG3OLQQNJYHANCNFSM4JFI2YQA> .

[CervEdin]

There's a reason solvers and local search algorithms aren't implemented in high level languages. They're not suited for solving NP-hard problems.

If you really need to do this client side, you could look into packages like https://www.npmjs.com/package/simulated-annealing or https://github.com/njoubert/csp.js.

If you just need a simpler interface for modelling optimization problems client-side, check out the MiniZinc project.

[kjartanm]

An experimental/poc wasm-version of or-tools is available at https://github.com/kjartanm/wasm-or-tools (and wasm is not exactly high level :) )

[Mizux]

Copy of the mailing list topic: Proof of concept WASM-build of OR-Tools

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)
  kjartanm@ef4b4fa
  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. kjartanm@17a87e1#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:

-    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: kjartanm@ed4d870

• 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...

[Mizux]

On archlinux:

pacman -S emscripten
cat /usr/lib/emscripten/cmake/Modules/Platform/Emscripten.cmake

[luiscastro193]

This would be very useful. Is there an easy way to compile or-tools with emscripten?

[Mizux]

@luiscastro193 now or-tools, on master branch, support CMAKE_TOOLCHAIN_FILES for C++, see https://github.com/google/or-tools/blob/master/tools/cross_compile.sh

[luiscastro193]

Ok so I followed these steps:

1. Cloned the branch
2. Edited line 209 of the file at the build function as emcmake cmake -S. -B"${BUILD_DIR}" "${CMAKE_DEFAULT_ARGS[@]}" "${CMAKE_ADDITIONAL_ARGS[@]}"
3. Set export TARGET=x86_64 and export PROJECT=or-tools
4. Executed ./cross_compile.sh build

However, the building process fails at some point: output.txt

Am I doing something wrong?

[kjartanm]

I added

  case ${TARGET} in
    wasm32)
      expand_wasm_config
      declare -r QEMU_ARCH=DISABLED ;;
    x86_64)

to have wasm as a target, and

function expand_wasm_config() {
  declare -r TOOLCHAIN_FILE=${PROJECT_DIR}/emscripten/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake
  CMAKE_ADDITIONAL_ARGS+=( -DCMAKE_TOOLCHAIN_FILE="${TOOLCHAIN_FILE}" -DBUILD_SAMPLES=OFF -DBUILD_EXAMPLES=OFF -DBUILD_TESTING=OFF)
}

to set the toolchain and turn off some parts of the process.

It runs for a good while, but kicks the bucket around 85%, after Built target ortools_constraint_solver.

[kjartanm]

The blockers for compiling seems to be the same 2 minor points that I addressed in my PoC-build (https://github.com/kjartanm/wasm-or-tools -- I cleaned it up a bit, so it is less hacky than to begin with :) )

It can be handled using EMSCRIPTEN preprocessor variable. Would something like this be an option?

glop/lp_solver.cc, 160:

  // Note that we only activate the floating-point exceptions after we are sure
  // that the program is valid. This way, if we have input NaNs, we will not
  // crash.
#ifndef __EMSCRIPTEN__  
  ScopedFloatingPointEnv scoped_fenv;
  if (absl::GetFlag(FLAGS_lp_solver_enable_fp_exceptions)) {
#ifdef _MSC_VER
    scoped_fenv.EnableExceptions(_EM_INVALID | EM_ZERODIVIDE);
#else
    scoped_fenv.EnableExceptions(FE_DIVBYZERO | FE_INVALID);
#endif
  }
#endif

base/raw_logging.cc, 28:

#if !defined(_MSC_VER) && !defined(__EMSCRIPTEN__)
#include <sys/syscall.h>  // for syscall()
#define safe_write(fd, s, len) syscall(SYS_write, fd, s, len)
#else
#if !defined(__EMSCRIPTEN__)
#include <io.h>  // _write()
// Not so safe, but what can you do?
#define safe_write(fd, s, len) _write(fd, s, len)
#else
#define safe_write(fd, s, len) write(fd, s, len)
#endif
#endif

[lperron]

Yes send us a PR. Le mer. 17 févr. 2021 à 08:41, Kjartan Müller <notifications@github.com> a écrit :

…

The blockers for compiling seems to be the same 2 minor points that I addressed in my PoC-build (https://github.com/kjartanm/wasm-or-tools -- I cleaned it up a bit, so it is less hacky than to begin with :) ) It can be handled using *EMSCRIPTEN* preprocessor variable. Would something like this be an option? glop/lp_solver.cc, 160: // Note that we only activate the floating-point exceptions after we are sure // that the program is valid. This way, if we have input NaNs, we will not // crash. #ifndef __EMSCRIPTEN__ ScopedFloatingPointEnv scoped_fenv; if (absl::GetFlag(FLAGS_lp_solver_enable_fp_exceptions)) { #ifdef _MSC_VER scoped_fenv.EnableExceptions(_EM_INVALID | EM_ZERODIVIDE); #else scoped_fenv.EnableExceptions(FE_DIVBYZERO | FE_INVALID); #endif } #endif base/raw_logging.cc, 28: #if !defined(_MSC_VER) && !defined(__EMSCRIPTEN__) #include <sys/syscall.h> // for syscall() #define safe_write(fd, s, len) syscall(SYS_write, fd, s, len) #else #if !defined(__EMSCRIPTEN__) #include <io.h> // _write() // Not so safe, but what can you do? #define safe_write(fd, s, len) _write(fd, s, len) #else #define safe_write(fd, s, len) write(fd, s, len) #endif #endif — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1670 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3NBSXU2JKWZCVCQR5TS7NXI7ANCNFSM4JFI2YQA> .

[kjartanm]

I have sent a PR for glop/lp_solver.cc and base/raw_logging.cc, but I also have a suggestion for cross_compile.sh that is currently in master. I have understood it so that you only want PRs on stable?

[tobiasBora]

What is the current status of this issue in 2026? (seems like your fork is abandonned) Is or-tool now natively supporting wasm?

[lperron]

No, on master Le sam. 20 févr. 2021 à 10:47, Kjartan Müller <notifications@github.com> a écrit :

…

I have sent a PR for glop/lp_solver.cc and base/raw_logging.cc, but I also have a suggestion for cross_compile.sh that is currently in master. I have understood it so that you only want PRs on stable? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1670 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3PSVASPUOUZXDWP633S76AMFANCNFSM4JFI2YQA> .

[abhijith96]

Has anyone successfully cross built or tools for emscripten(web assembly) without hacks.

[abhijith96]

Thanks a lot, May I know what was the final size of package for release mode after cross compiling using emscripten.

[kjartanm]

The total build from the cross compile of or-tools seems to be 105 Mb. The compiled wasm for the sudoku-solver is 1,3 Mb.

[abhijith96]

105 Mb seems good. Did u cross compile using the linux environment.

[kjartanm]

You set wasm32 as target.

[Nofalpro]

@kjartanm I can certainly assure you that your article and fork have been really useful to our Blazor wasm project, we get to keep our wasm app model and use powerful tools. Thanks!

I have noticed also that it has been added recently to v9.4 Milestones which is fantastic as I really need the new version of OR-Tools due to some missing functions back then and im still trying to build of off your work for v9.3.