* Showing a (preferred) CMake 3.13 syntax, as the features of treating
libraries starting with a dash as a link flag is just an internal
and not really documented CMake feature
* Removed reference to --pre-js, as this knowledge isn't needed to
accomplish this anymore. The last paragraph and code snippet was
also redundant.
By wrapping the module creation in a function that includes properties
from the original module as well as allowing to override the default
properties from the outside. This also means it's possible to create
differently named modules for multiple applications on the page.
And properly account for -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR.
Module['canvas'] can be read even from code compiled with -s MODULARIZE
so it's a preferrable option to hardcoding it in Configuration. The
target strings in Emscripten depend on whether we're compiled with
DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR (see
https://github.com/emscripten-core/emscripten/pull/7977). This is now
detected and handled at runtime to prepend element IDs with and use
the correct window and document magic targets.
Not yet sure about all interactions with older Emscripten versions and
DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR set to 0, reverting until
it's clear.
This reverts commit c760acb548.
It doesn't really work for tests that depend on more than one plugin
(because there i would need to handle all combinations, somehow), but it
does the job when the end user has such use case.
First of all, it's quite unusual to have an array of const chars. Then,
it was not really handling file opening errors, which is actually a VERY
BAD THING when you are wondering why your include isn't parsed.
Like, it's INEVITABLE to have a 100-line std::lerp() implementation for
questionable reasons but such dead-simple thing as std::pair doing moves
instead of copies where expected that should have been done CORRECTLY
back in 2011 still isn't working reliably across implementations?!
I guess I'm doing my Containers::Pair soon as well, then.