Building a worker
Supported compilers and runtimes
Compiling and linking
The way that you’ll be using the contents of the worker packages depends entirely on which language will be using the Worker SDK in C. Each worker package specified above contains the following structure:
<worker_package>/include/improbable- This folder contains two header files:
c_worker.h- The worker API, including connecting to SpatialOS and interacting with snapshots.
c_schema.h- The schema API, used to serialize / deserialize components and commands.
<worker_package>/lib- This folder only exists in static packages, and contains static libraries for the Worker SDK in C and its dependencies. On non-Windows platforms, you’ll need to ensure that these libraries are linked in the following order:
<worker_package>/worker.dll- This file only exists in dynamic packages. This file is the dynamic library which is designed to be loaded by a dynamic language such as Python (or linked to a native executable using the dynamic linker). This file is named
worker.bundlein the macOS and iOS packages, and
libworker.soin the Linux and Android packages.
Building for a cloud deployment
After building a project, a certain directory structure is expected when
uploading an assembly.
Therefore, the steps of the Build task for your worker (within
Create a zip file containing the worker binary with a name matching the value for the
artifact_namespecified in the managed worker configuration, under
Place the zip file in
<project_root>/build/assembly/worker/, so it is picked up when uploading an assembly during
spatial cloud upload <assembly name>.
SpatialOS runs managed workers as part of a cloud deployment in a Linux environment similar to Ubuntu 16.04 LTS. Therefore, you need to build a binary that can be executed in this environment.
If you are developing on Windows or macOS, we suggest installing Ubuntu 16.04 LTS inside a virtual machine using VirtualBox, and using our Linux support to build managed workers. Alternatively, on Windows 10, you can install Ubuntu using the Windows Subsystem for Linux instead of a virtual machine. This is not required for local deployments during development: just for cloud deployments.