Build on emscripten

[llandsmeer]

Driving arbor adoption is easier if we could build an accessible browser interface for 'getting-started' tutorials on arbor.

With some modifications, I was able to build and run arbor using emscripten

1. Build a normal modcc (for nmodl -> cpp conversion)
2. Build emscripten arbor without modcc

we need the 'generic' architecture because the default 'native' is not supported by emscripten

cmake .. \
    --toolchain /usr/share/emscripten/cmake/Modules/Platform/Emscripten.cmake \
    -DARB_USE_BUNDLED_LIBS=ON \
    -DARB_MODCC=/path/to/amd64/modcc \
    -DARB_ARCH=generic
make -j 8 examples

3. Run some examples

$ node bin/gap_junctions.jas
gpu:      no
threads:  1
mpi:      no
ranks:    1

Using default parameters.
running simulation

30 spikes generated at rate of 3.33333 ms between spikes

---- meters -------------------------------------------------------------------------------
meter                         time(s)
-------------------------------------------------------------------------------------------
model-init                      0.001
model-run                       0.037
meter-total                     0.038

During porting I found some problems:

Broken custom modcc cmake flag

A custom modcc is not supported by cmake. There is the -DARB_MODCC flag which supposedly does that, but it's value is never read.

set(ARB_MODCC "" CACHE STRING "path to external modcc NMODL compiler")

Instead to make it build I had to change the CMakeLists.txt a bit

-set(modcc $<TARGET_FILE:modcc>)
-set(ARB_MODCC_FLAGS)
-if(ARB_VECTORIZE)
-    list(APPEND ARB_MODCC_FLAGS "--simd")
-endif()
+# set(modcc $<TARGET_FILE:modcc>)
+# set(ARB_MODCC_FLAGS)
+# if(ARB_VECTORIZE)
+# list(APPEND ARB_MODCC_FLAGS "--simd")
+# endif()
+
+# set(modcc ${ARB_MODCC})
+# set(modcc ${ARB_MODCC})
+set(modcc "/home/llandsmeer/repos/llandsmeer/arbor/build-master-simple/prefix/bin/modcc")

 [..]

-add_subdirectory(modcc)
+# add_subdirectory(modcc)

Random123 breaks intentionally

Because of this code:

#if !defined(__x86_64__) && !defined(__i386__) && !defined(__powerpc__) && !defined(__arm__) && !defined(__aarch64__) && !defined(__s390x__)
#  error "This code has only been tested on x86, powerpc and a few arm platforms."
#include <including_a_nonexistent_file_will_stop_some_compilers_from_continuing_with_a_hopeless_task>
{ /* maybe an unbalanced brace will terminate the compilation */
 /* Feel free to try the Random123 library on other architectures by changing
 the conditions that reach this error, but you should consider it a
 porting exercise and expect to encounter bugs and deficiencies.
 Please let the authors know of any successes (or failures). */
#endif

removing it makes the code build and run just fine

Can't run tests without modcc

modcc doesn't work in a emscripten setting (mostly because there is no gcc in the browser). this means the modcc-unit tests will fail. I could not find a way to build the tests.

Should we make emscripten a build target?

I think adding emscripten as an officially supported build target would be a lot of development effort in the long run, but maybe it's a good idea to keep the code in a shape that someone with porting experience can make it compile.

If people think it's worth it, I'd like to make these changes into a PR

[thorstenhater]

We need modcc after building the internal catalogues for two things

1. the tests (as you noticed)
2. building external catalogues in dynamically linked libraries

both are optional in a browser based setting.

The other thing that has stopped me from compiling Arbor using emscripting before was libxml, which is used by NML support. That, too, might be considered optional in the browser.

So, yes, I think it's interesting to have a browser showcase. By necessity it would involve build the GUI project alongside, I assume?

[llandsmeer]

I also managed to build a Pyodide wheel for arbor, which enables us to run arbor python code (like the tutorials) in browser

More problems:

The python cmake file is very much tied to the host python. The pyodide-build system creates a virtual env and separate compiler toolchain, but that breaks when building the arbor python package. Instead I had to build manually:

em++ \
    ../python/*.cpp \
    -I ../ext/pybind11/include/ \
    -I /home/llandsmeer/tmp/xbuildenv/pyodide-root/cpython/installs/python-3.10.2/include/python3.10/ \
    -I ../build-emscripten/prefix/include \
    -std=c++20 \
    ../build-emscripten-3.1.12/prefix/lib/libarbor* \
    -o _arbor.cpython-310-wasm32-emscripten.so \
    -shared -fPIC \
    -s ALLOW_MEMORY_GROWTH=1 \
    -s FORCE_FILESYSTEM=1 \
    -s LINKABLE=1 \
    -s USE_SDL=0 \
    -s SIDE_MODULE=1 \
    -s MODULARIZE=1 \
    -s WASM_BIGINT=1 \
    -g0 \
    -O2

and then manually constructing a arbor wheel file by copying over the WHEEL, METADATA, init.py and VERSION files and zipping that up.

I think either a very basic ('run/edit this python example look a the voltage traces') or full arbor-gui port are indeed the best options