Assuming the user/project does not specify a CMAKE_INSTALL_PREFIX
to install to we can and should default to installing into the
emscripten sysroot.
Also, add a test that uses `cmake --install` to install a library and
the `finc_package` to find the library config.
This confirms that #6595 is fixed even though technicall the fix landed
in in #14291
Also, add more testing in order to verify that finding resources
inside the sysroot works as expected.
See: https://github.com/emscripten-core/emsdk/issues/824#
See: #6595
I'm not sure if this is also fixes#6595 and will likely followup with a
test for find_package.
Fixes: #10078
This is needed for test_cmake_compile_features to pass after cmake
3.20.0.
This is needed to because something changed with the circleci macOS
image that cause the cmake version to go from 3.18.4 (cmake-3.18.4.catalina.bottle.tar.gz)
to 3.20.2. Its not totally clear to me what changed on the circleci side but it seems like they
had to update homebrew in a hurry:
https://discuss.circleci.com/t/macos-images-need-homebrew-update-urgently/39748/5
It's a bit of a surprise that `Emscripten.cmake` overrides the
defaults for CMake's C/C++ compiler and linker flags. In particular
`RelWithDebInfo` by default doesn't include debugging information.
From the history of this file it wasn't clear why this decision was
made in the first place, but nowadays there doesn't seem to be a
good reason to keep doing it.
Only output object files if `-c`, `-r` or `-shared` is specified.
We have a `link_to_object` mode which was previously used by default
if the output didn't end with EXECUTABLE_ENDINGS. After this change
`link_to_object` is only used if `-r` or `-shared` are passed
explicitly.
This allows linking executables (JS files) with arbitrary extensions.
For example, I can do `emcc foo.c -o foo.txt` and I will actually get a
JS file called `foo.txt`. This matches the behaviour of clang and gcc.
This removes some rather unhelpful errors and warnings that we were
needless generating when this `link_to_object` mode was automatically
triggered.
It also allowed me to do some refactoring to move js_target and
final_suffix declarations closer to their actual first use.
See: #11753
Replaces: #7697
When building in RelWithDebInfo mode, you want debug info (-g)
but not debug code. Most compilers in the cmake distribution
enable -DNDEBUG in all release configurations.
This only ever worked in spidermonkey and I don't think we care
about asmjs validation anymore anyway.
Perhaps this should wait until after we remove fastcomp which is the
only route to generating valid asm.js that we still maintain.
Toolchain cmakes generally don't define cmake_minimum_required.
See official toolchains here:
https://github.com/Kitware/CMake/tree/master/Modules/Platform
This also eliminates possible CMP0063 warnings coming from
`em_link_js_library` and similar when using cmake 3.3.0 or newer.
CMake 3.15 and later weren't correctly handling `CMAKE_CXX_STANRDARD`
and friends when using the emscripten cmake modules. This was because
there is a new variable that needs to be set to indicate whether
the compiler is using GNU or MSVC command line options.
Fixes#9100
It was there because we couldn't rely on wasm support being in node, but these days it is in node LTS (and in the node we ship with the emsdk). Using wasm avoids using wasm2js there which might be a problem with the wasm backend, as it doesn't support 100% of features.
There is some risk here - wasm does behave differently in some ways, like having a separate file, having async startup. Without seeing a concrete problem though it's not worth trying to add hacks for those things. But I do worry that we don't have enough test coverage here, as this PR fixes#8848 (see more details there) which noticed issues we don't cover in the test suite (but that I'm not sure are worth adding - basically, things that wasm2js can't do).
These simple changes allow for C++17 support in CMake projects with
Emscripten:
~~~
set(CMAKE_CXX17_COMPILE_FEATURES "cxx_std_17")
~~~
Tested both sdk-incoming-64bit and sdk-wasm-master-64bit.
Modified line was pulled from a known working generated `CMakeCXXCompiler.cmake` by CMake (version `3.13.4`)
This matches what clang and gcc do. This change specifically
fixes `other.test_cmake` with the llvm backend, because the cmake
code that checks for emscripten was checking for the word
emscripten in stderr and not stdout.
For the fastcomp this is fine because the word emscripten appears
in the stderr of `clang -v`, but for the llvm backend we rely on
the first line of `emcc -v` output which contains the word emscripten.
For reference once the output `emcc -v` is something like like this:
```
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 1.38.11
clang version 8.0.0 (trunk 340421) (llvm/trunk 340423)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/google/home/sbc/dev/wasm/llvm-build/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.4.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/7.3.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8.0.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8.0.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.3.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
```
Prior to this change the first line went to stdout and the rest
to stderr.
Add EMSCRIPTEN_VERSION variable to user CMake scripts so that they can do
if ("${EMSCRIPTEN_VERSION}" VERSION_GREATER 1.38.6)
to check for a particular Emscripten version.
This changes the default output from asm.js to WebAssembly. Only the default is changed - we of course still support asm.js, and will for a very long time. But changing the default makes sense as the recommended output for most use cases should be WebAssembly, given it has shipped in all major browsers and platforms and is more efficient than asm.js.
The main changes in this PR are:
* The actual flipping of the switch to wasm.
* Cleanups in emcc.py and emscripten.py for that flag change - I swapped all BINARYEN to WASM, which made reading the a code a lot easier, at least for me. I also added some clearer warnings/errors for mismatched flags (features we just support in asm.js, like split memory).
* Update the test suite. A lot of tests required some changes, e.g. because some are actually asm.js tests (so we must force wasm off) or they assume sync startup (which wasm does not do by default), etc. This is a big change, but nothing really sophisticated there.
* Update the tutorial, FAQ, optimization docs, etc.
* Make LEGACY_VM_SUPPORT flip off wasm. When targeting old VMs, IE11, etc., wasm doesn't make sense. As a result, this PR should not break code using that option.
* Without the EMCC_BROWSER_ALSO_ASMJS env var, we just run browser tests normally (using wasm, unless a test says otherwise). But pthreads tests we run in asm.js since wasm isn't stable yet. And with that env var, we run the test also in asm.js mode (we don't need the extra also_asmjs arg to do that, can just look at the arguments, do they disable wasm or not).
Do no overwrite CMAKE_FIND_ROOT_PATH, this enables 3rd party
extensions to emscripten CMake scripts, such as *Config.cmake files to
emulate emscripten's built in libraries
This variable was added in recent CMake Git master. It should point to an
executable that acts like an emulator for the target system when
cross-compiling. For emscripten, this is nodejs.
This executable is used by CMake to run executables in try_run commands. By
adding support for this variable, it prevents the need to manually populate
the tedious TryRunResults.cmake file.
The emscripten configured path to NodeJS is added to the emcmake command. In
the Emscripten.cmake file, if CMAKE_CROSSCOMPILING_EMULATOR is not defined
(which is would be if using emcmake), and attempt is made to find nodejs and
use it.
Sam Clegg
Benedikt Meurer
Clément Grégoire
Bruce Mitchener
Gabriel
Paul Du
Derek Schuff
András Kucsma
Alon Zakai
Shane Peelar
Alon Zakai (kripken)
juj
Jacob Gravelle
Alexandre Pretyman
mhenschel
Matt McCormick
Nicholas Wilson