2021-01-01 18:45:43 +01:00
# Emscripten {#emscripten}
2018-03-18 13:34:46 +01:00
[Emscripten ](https://github.com/kripken/emscripten ): An LLVM-to-JavaScript Compiler
This section of the manual covers how to use `emscripten` in nixpkgs.
Minimal requirements:
* nix
* nixpkgs
Modes of use of `emscripten` :
* **Imperative usage** (on the command line):
If you want to work with `emcc` , `emconfigure` and `emmake` as you are used to from Ubuntu and similar distributions you can use these commands:
2021-11-08 13:00:00 +01:00
* `nix-env -f "<nixpkgs>" -iA emscripten`
2018-03-18 13:34:46 +01:00
* `nix-shell -p emscripten`
* **Declarative usage**:
2021-11-08 13:00:00 +01:00
This mode is far more power full since this makes use of `nix` for dependency management of emscripten libraries and targets by using the `mkDerivation` which is implemented by `pkgs.emscriptenStdenv` and `pkgs.buildEmscriptenPackage` . The source for the packages is in `pkgs/top-level/emscripten-packages.nix` and the abstraction behind it in `pkgs/development/em-modules/generic/default.nix` . From the root of the nixpkgs repository:
2020-07-31 07:06:53 +02:00
* build and install all packages:
* `nix-env -iA emscriptenPackages`
* dev-shell for zlib implementation hacking:
* `nix-shell -A emscriptenPackages.zlib`
2018-03-18 13:34:46 +01:00
2021-06-05 21:22:45 +02:00
## Imperative usage {#imperative-usage}
2018-03-18 13:34:46 +01:00
A few things to note:
* `export EMCC_DEBUG=2` is nice for debugging
* `~/.emscripten` , the build artifact cache sometimes creates issues and needs to be removed from time to time
2021-06-05 21:22:45 +02:00
## Declarative usage {#declarative-usage}
2018-03-18 13:34:46 +01:00
Let's see two different examples from `pkgs/top-level/emscripten-packages.nix` :
* `pkgs.zlib.override`
* `pkgs.buildEmscriptenPackage`
Both are interesting concepts.
A special requirement of the `pkgs.buildEmscriptenPackage` is the `doCheck = true` is a default meaning that each emscriptenPackage requires a `checkPhase` implemented.
* Use `export EMCC_DEBUG=2` from within a emscriptenPackage's `phase` to get more detailed debug output what is going wrong.
* ~/.emscripten cache is requiring us to set `HOME=$TMPDIR` in individual phases. This makes compilation slower but also makes it more deterministic.
2021-06-05 21:22:45 +02:00
### Usage 1: pkgs.zlib.override {#usage-1-pkgs.zlib.override}
2018-03-18 13:34:46 +01:00
This example uses `zlib` from nixpkgs but instead of compiling **C** to **ELF** it compiles **C** to **JS** since we were using `pkgs.zlib.override` and changed stdenv to `pkgs.emscriptenStdenv` . A few adaptions and hacks were set in place to make it working. One advantage is that when `pkgs.zlib` is updated, it will automatically update this package as well. However, this can also be the downside...
See the `zlib` example:
zlib = (pkgs.zlib.override {
stdenv = pkgs.emscriptenStdenv;
2023-02-23 17:09:09 +01:00
}).overrideAttrs
2018-03-18 13:34:46 +01:00
(old: rec {
2021-01-19 04:19:48 +01:00
buildInputs = old.buildInputs ++ [ pkg-config ];
2018-03-18 13:34:46 +01:00
# we need to reset this setting!
2023-02-20 16:17:34 +01:00
env = (old.env or { }) // { NIX_CFLAGS_COMPILE = ""; };
2018-03-18 13:34:46 +01:00
configurePhase = ''
# FIXME: Some tests require writing at $HOME
HOME=$TMPDIR
runHook preConfigure
#export EMCC_DEBUG=2
emconfigure ./configure --prefix=$out --shared
runHook postConfigure
'';
dontStrip = true;
outputs = [ "out" ];
buildPhase = ''
emmake make
'';
installPhase = ''
emmake make install
'';
checkPhase = ''
echo "================= testing zlib using node ================="
echo "Compiling a custom test"
set -x
emcc -O2 -s EMULATE_FUNCTION_POINTER_CASTS=1 test/example.c -DZ_SOLO \
libz.so.${old.version} -I . -o example.js
echo "Using node to execute the test"
2020-07-31 07:06:53 +02:00
${pkgs.nodejs}/bin/node ./example.js
2018-03-18 13:34:46 +01:00
set +x
if [ $? -ne 0 ]; then
echo "test failed for some reason"
exit 1;
else
echo "it seems to work! very good."
fi
echo "================= /testing zlib using node ================="
'';
2021-01-10 20:08:30 +01:00
postPatch = pkgs.lib.optionalString pkgs.stdenv.isDarwin ''
2018-03-18 13:34:46 +01:00
substituteInPlace configure \
--replace '/usr/bin/libtool' 'ar' \
--replace 'AR="libtool"' 'AR="ar"' \
--replace 'ARFLAGS="-o"' 'ARFLAGS="-r"'
'';
});
2021-06-05 21:22:45 +02:00
### Usage 2: pkgs.buildEmscriptenPackage {#usage-2-pkgs.buildemscriptenpackage}
2018-03-18 13:34:46 +01:00
2020-07-31 07:06:53 +02:00
This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used.
2018-03-18 13:34:46 +01:00
xmlmirror = pkgs.buildEmscriptenPackage rec {
name = "xmlmirror";
2021-01-19 04:19:48 +01:00
buildInputs = [ pkg-config autoconf automake libtool gnumake libxml2 nodejs openjdk json_c ];
nativeBuildInputs = [ pkg-config zlib ];
2018-03-18 13:34:46 +01:00
src = pkgs.fetchgit {
url = "https://gitlab.com/odfplugfest/xmlmirror.git";
rev = "4fd7e86f7c9526b8f4c1733e5c8b45175860a8fd";
doc: use sri hash syntax
The nixpkgs manual contains references to both sri hash and explicit
sha256 attributes. This is at best confusing to new users. Since the
final destination is exclusive use of sri hashes, see nixos/rfcs#131,
might as well push new users in that direction gently.
Notable exceptions to sri hash support are builtins.fetchTarball,
cataclysm-dda, coq, dockerTools.pullimage, elixir.override, and
fetchCrate. None, other than builtins.fetchTarball, are fundamentally
incompatible, but all currently accept explicit sha256 attributes as
input. Because adding backwards compatibility is out of scope for this
change, they have been left intact, but migration to sri format has been
made for any using old hash formats.
All hashes have been manually tested to be accurate, and updates were
only made for missing upstream artefacts or bugs.
2022-12-03 20:49:00 +01:00
hash = "sha256-i+QgY+5PYVg5pwhzcDnkfXAznBg3e8sWH2jZtixuWsk=";
2018-03-18 13:34:46 +01:00
};
configurePhase = ''
rm -f fastXmlLint.js*
# a fix for ERROR:root:For asm.js, TOTAL_MEMORY must be a multiple of 16MB, was 234217728
# https://gitlab.com/odfplugfest/xmlmirror/issues/8
sed -e "s/TOTAL_MEMORY=234217728/TOTAL_MEMORY=268435456/g" -i Makefile.emEnv
# https://github.com/kripken/emscripten/issues/6344
# https://gitlab.com/odfplugfest/xmlmirror/issues/9
sed -e "s/\$(JSONC_LDFLAGS) \$(ZLIB_LDFLAGS) \$(LIBXML20_LDFLAGS)/\$(JSONC_LDFLAGS) \$(LIBXML20_LDFLAGS) \$(ZLIB_LDFLAGS) /g" -i Makefile.emEnv
# https://gitlab.com/odfplugfest/xmlmirror/issues/11
sed -e "s/-o fastXmlLint.js/-s EXTRA_EXPORTED_RUNTIME_METHODS='[\"ccall\", \"cwrap\"]' -o fastXmlLint.js/g" -i Makefile.emEnv
'';
buildPhase = ''
HOME=$TMPDIR
make -f Makefile.emEnv
'';
outputs = [ "out" "doc" ];
installPhase = ''
mkdir -p $out/share
mkdir -p $doc/share/${name}
cp Demo* $out/share
cp -R codemirror-5.12 $out/share
cp fastXmlLint.js* $out/share
cp *.xsd $out/share
cp *.js $out/share
cp *.xhtml $out/share
cp *.html $out/share
cp *.json $out/share
cp *.rng $out/share
cp README.md $doc/share/${name}
'';
checkPhase = ''
'';
2020-07-31 07:06:53 +02:00
};
2018-03-18 13:34:46 +01:00
2021-06-05 21:22:45 +02:00
### Declarative debugging {#declarative-debugging}
2018-03-18 13:34:46 +01:00
Use `nix-shell -I nixpkgs=/some/dir/nixpkgs -A emscriptenPackages.libz` and from there you can go trough the individual steps. This makes it easy to build a good `unit test` or list the files of the project.
1. `nix-shell -I nixpkgs=/some/dir/nixpkgs -A emscriptenPackages.libz`
2. `cd /tmp/`
3. `unpackPhase`
4. cd libz-1.2.3
5. `configurePhase`
6. `buildPhase`
7. ... happy hacking...
2021-06-05 21:22:45 +02:00
## Summary {#summary}
2018-03-18 13:34:46 +01:00
Using this toolchain makes it easy to leverage `nix` from NixOS, MacOSX or even Windows (WSL+ubuntu+nix). This toolchain is reproducible, behaves like the rest of the packages from nixpkgs and contains a set of well working examples to learn and adapt from.
If in trouble, ask the maintainers.