At Tableau, we've seen issues with CMake/Ninja building multiple .js files (test suites) and an empty cache. No bugs, but it does end up building the same cached libraries multiple times.
On Friday, July 1, 2016 at 3:19:43 PM UTC-7, Floh wrote: > > I did a few test runs with the Oryol samples, 3 or 6 make jobs, and ninja > (this parallelizes quite heavily by default), each time deleting the cache, > and didn't encounter any problems, the cache entries were only built once > (at least according the console messages). > > Before, I did have many parallel console outputs for rebuilding the cache > contents in the different build job processes, since several samples were > hitting the linker stage at nearly the same time. In the past I first built > a single sample to let the cache rebuild just to make sure. It's nice that > this is no longer necessary :) > > Cheers, > -Floh. > > Am Mittwoch, 29. Juni 2016 23:02:56 UTC+2 schrieb jj: >> >> Hey all! >> >> We had a few fixes go in to how multiple Emscripten processes behave with >> respect to sharing the same cache directory. See >> https://github.com/kripken/emscripten/pull/4404 for details. Basically, >> accesses to the Emscripten cache should now be multiprocess safe, as long >> as all the Emscripten processes accessing the cache are of the same >> compiler version. >> >> Previously, if one configured a project e.g. with CMake, and then did >> "make -jX" with an empty Emscripten cache (or after having modified a >> configuration so the cache would clear), all the Emscripten compiler >> invocations would start racing to rebuild the files to cache. That is, the >> following code sequence was not supported: >> >> emcc --clear-cache (or manually nuke ~/.emscripten_cache for clean >> install) >> cmake <args> >> make -jX >> >> The workaround that was needed was to manually rebuild the cache in >> single process mode: >> >> emcc --clear-cache (or manually nuke ~/.emscripten_cache for clean >> install) >> cmake <args> >> python emscripten/embuilder.py build ALL // prepopulate the cache before >> multithreaded build >> make -jX >> >> After PR #4404, the manual workaround is no longer needed, but make -jX >> operation should be safe for projects. If this has been a pain point >> before, please try it out now and let us know how it works out. The >> Emscripten test suites have been tested to pass with this, but it is >> naturally possible that there's still some disk access race conditions >> lurking somewhere, so it would be great to have some eyeballs to stress >> this out. >> >> If you are using Emscripten SDK, you can update to the latest version via >> the usual set of commands >> >> ./emsdk install sdk-incoming-64bit >> ./emsdk activate sdk-incoming-64bit >> source ./emsdk_env.sh >> >> on Mac OS X and Linux, and on Windows >> >> emsdk install sdk-incoming-64bit >> emsdk activate sdk-incoming-64bit >> emsdk_env >> >> N.b. that this feature is mostly aimed for "make -jX" support. If you >> have multiple different Emscripten SDKs installed and running >> simultaneously, possibly with different compiler versions, then it is a >> good idea to have those live fully in separate SDK paths, and use the >> Emscripten SDK "--embedded" feature to box them out in their own >> subdirectories. That is, run: >> >> ./emsdk install sdk-incoming-64bit >> ./emsdk activate --embedded sdk-incoming-64bit >> source ./emsdk_env.sh >> >> after which the given instance of Emscripten SDK operates fully inside >> its root directory, and doesn't touch e.g. the user's home directory ~/ at >> all. >> >> Finally, if you are not using Emscripten SDK but are building all pieces >> manually from source, then you can achieve the same thing that --embedded >> does by setting the EM_CONFIG environment variable before building. >> >> Cheers, >> Jukka >> >> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
