Clarify how to compile from source a little more #9383
Conversation
|
tools/ports/binaryen.py is just out of date think. I don't think it gets a lot attention of testing/attension because most users are either using emsdk (most end users), or directly working with a binaryen source tree (i.e. core emscripten devs). |
There was a problem hiding this comment.
Nice, thanks @Beuc!
For the LLVM / Binaryen versions, can link to https://github.com/emscripten-core/emscripten/blob/incoming/docs/process.md#packaging-emscripten
|
Good points about the binaryen port version. It's basically broken as it is, and untested. How about if we just remove it entirely, as planned, now that we have it properly built in the emsdk like llvm? |
| cmake .. -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS='lld;clang' -DLLVM_TARGETS_TO_BUILD="host;WebAssembly" -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF | ||
| cd build/ | ||
| cmake ../llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS='lld;clang' -DLLVM_TARGETS_TO_BUILD="host;WebAssembly" -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF | ||
| make -j$(nproc) # no need to install |
There was a problem hiding this comment.
I would replace this with ninja since it does automatic parallelism.
And perhaps replace no need to install with a followup paragraph saying something like "Then setting your LLVM_ROOT in .emscripten to point to <llvm_src>/build/bin"
There was a problem hiding this comment.
Using ninja complexifies the cmake command, and doesn't seem to check for available memory, so I'll leave this part out (cmake --build .).
There was a problem hiding this comment.
I believe the ninja generator is smart enough to perform compilation with high level of parallelism and one a very low level (1 or 2 jobs in parallel) when does linking. This is something that helps a lot with OOM and large links. . and something I don't think make can do at all. Just one of many reasons to choose ninja. Although you are right its probably out of scope for these instructions.
|
|
||
| Please refer to the upstream docs for more detail. | ||
|
|
||
| The version to select for e.g. 1.38.43 is --- TODO ---. |
There was a problem hiding this comment.
I don't think you need this. Users building from source normally just want ToT.
There was a problem hiding this comment.
Hmm, in my experience I needed 1 patch (emscripten-core/emscripten-fastcomp#195) for fastcomp but otherwise stuck to identified, reproducible releases. I'll add kripken's link as well.
There was a problem hiding this comment.
I guess it depends who you are targeting with these instructions. If you want to build a pinned release from source then emsdk is the easiest way to do that. It can download and build everything from source in a single command. I assume these instructions are targetting people who want to work on the sources in place?
However I don't see any harm in documenting that the fastcomp and binaryen are tagged with emscripten releases. Remember upstream llvm has no such tags though.
There was a problem hiding this comment.
If emsdk can rebuild everything from source, including a patch or two, then that sounds like something to write proeminently here! I had no idea.
Is that working for -upstream yet, I didn't find the right 'emsdk install' tag?
There was a problem hiding this comment.
emsdk only knows how to build pinned releases. So you don't get a chance to edit or patch the code in that case.
Thats why I assumed these instructions were more directed at people who want to work on the codebase.
Perhaps we should add link to this doc saying something like: Unless you need to modify of customize llvm or binaryen then emsdk is the easiest way to build them from srouce. See <link>.?
There was a problem hiding this comment.
I only found https://github.com/emscripten-core/emsdk/blob/master/README.md#how-do-i-track-the-latest-emscripten-development-with-the-sdk which is about rebuilding master/incoming for fastcomp, maybe there's a better link.
|
I feel there is an ongoing misunderstanding about what I believe is a common use case for recompiling, so I detailed it at: |
|
lgtm too, thanks! |
Following-up on the discussion from #9317 :)
Besides a couple trivial fixes, I think we need to explain what version of LLVM and Binaryen needs to be checked-out.
Also, I'm not sure whether there's a bug in tools/ports/binaryen.py since it still references v86, while the emsdk binaries grab v89 AFAIU. If that's intended so probably needs to be clarified, because the port is built and used automatically when BINARYEN_ROOT is empty.