When writing new C/C++ in emscripten follow the LLVM style (as does binaryen). You can use clang-format
to automatically format new code (and git clang-format origin/main
to format just the lines you are changing). See .clang-format
for more details.
When editing third party code such (e.g. musl, libc++) follow the upstream conventions.
We use the same LLVM-based style as for C/C++. Sadly, clang-format
doesn't always work well with our library code since it can use custom macros and pre-processor. See .clang-format
for more details.
We generally follow the pep8 standard with the major exception that we use 2 spaces for indentation. flake8
is run on all PRs to ensure that python code conforms to this style. See .flake8
for more details.
We are beginning to use python3's type annotation syntax, along with the mypy
tool to check python types statically. See .mypy
for more details.
The goal is to one day check all type by running mypy
with --disallow-untyped-defs
, but this is happening incrementally over time.
When:
Requirements:
main
branch for the emscripten commit referred to in DEPS.How:
<non-LTO-sha>
.<LTO-sha>
. An example of this CL is https://chromium-review.googlesource.com/c/emscripten-releases/+/3781978.scripts/create_release.py
in the emsdk repository. When we do both an LTO and a non-LTO release, run:./scripts/create_release.py <LTO-sha> <non-LTO-sha>This will make the
<LTO-sha>
point to the versioned name release (e.g. 3.1.7
) and the <non-LTO-sha>
point to the assert build release (e.g. 3.1.7-asserts
). When we do only a non-LTO release, run:./scripts/create_release.py <non-LTO-sha>This will make the
<non-LTO-sha>
point directly to the versioned name release (e.g. 3.1.7
) and there will be no assert build release. If we run scripts/create_release.py
without any arguments, it will automatically pick a tot version from emscripten-releases repo and make it point to the versioned name release. Running this scripts/create_release.py
script will update emscripten-releases-tags.json, adding a new version. The script will create a new local git branch and push it up to origin
. An example of this PR is emscripten-core/emsdk#1071.emsdk
repo with the new version number, on the commit that does the update, after it lands on main.emscripten
repo with the new version number, on the commit referred to in the DEPS (or DEPS.tagged-release) file above.tools/maint/create_release.py
tool in the emscripten repo to update emscripten-version.txt
and ChangeLog.md
. An example of such PR is emscripten-core/emscripten#17439.When:
Requirements:
runner.py
), other
, browser
, sockets
, sanity
, binaryen*
. (Not all of those are run on all the bots.)How:
emscripten.org
WebsiteThe site is currently hosted in gh-pages
branch of the separate site repository. To update the docs, rebuild them and copy them into this repository. There is a script that will perform these steps automatically: tools/maint/update_docs.py
. Just run this script with no arguments if the emscripten-site repository is checked out alongside emscripten itself, or pass the location of the checkout if not.
You will need the specific sphinx version installed, which you can do using pip3 install -r requirements-dev.txt
(depending on your system, you may then need to add ~/.local/bin
to your path, if pip installs to there).
emcc.py
help textemcc --help
output is generated from the main documentation under site/
, so it is the same as shown on the website, but it is rendered to text. After updating emcc.rst
in a PR, the following should be done:
site
.make clean
(without this, it may not emit the right output).make text
.build/text/docs/tools_reference/emcc.txt
to ../docs/emcc.txt
(both paths relative to the site/
directory in emscripten that you entered in step 1), and add that change to your PR.See notes above on installing sphinx.