Removal of EMSCRIPTEN_ROOT from config file
TLDR: There is a field in called EMSCRIPTEN_ROOT in the config file which in theory can be used by external tools to find the "active" emscripten. I'm proposing to remove it. --- Maintaining this field has a cost and it can get out of sync with the emscripten you are actually using.Imagine you run `emcc` and if parses the config file and finds EMSCRIPTEN_ROOT pointing to different version of emscripten. The two current users of EMSCRIPTEN_ROOT that I know of are the scons support: https://github.com/kripken/emscripten/blob/incoming/tools/scons/site_scons/site_tools/emscripten/emscripten.py And ammo.js: https://github.com/kripken/ammo.js/blob/master/make.py#L17 In both of these cases a better solution would be either: 1) looks for `emcc` in the $PATH 2) check for EMSCRIPTEN_ROOT in the environment. Parsing the config file is also a rather brittle solution, and prevents us from iterating on the config file format and how its parses. It also uses python's `eval` which is nasty. Any objections to following this path? -- 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 emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stability of llvm-lto
LLVM LTO in general should be safe IIUC. At least when using upstream llvm I don't know of any issues. Perhaps there is something different with fastcomp that I'm not aware of. Perhaps we should remove that from the docs. On Tue, Oct 9, 2018 at 3:34 PM Александр Гурьянов wrote: > > Hi. I tried it couple of times. Problem is in undefined behaviour my > code works correctly most of time, but sometimes unpredictable erros > are happen. I decide to not use them, because it is impossible to > prove that output is working correctly. > > ср, 10 окт. 2018 г. в 0:09, Corey Lucier : > > > > We really wish to lean on LLVM link time optimizations. > > > > The Emscripten docs say . "LLVM LTO is not perfectly stable yet, and can > > cause code to behave incorrectly.". > > > > Does this note still apply? There's nothing saying what particular > > scenarios are problematic and I can't find equivalent docs in the LLVM > > project itself. > > > > So...are you guys actively discouraging it's use? > > > > Thanks, > > > > Corey > > > > -- > > 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 emscripten-discuss+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > 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 emscripten-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Stability of llvm-lto
Hi. I tried it couple of times. Problem is in undefined behaviour my code works correctly most of time, but sometimes unpredictable erros are happen. I decide to not use them, because it is impossible to prove that output is working correctly. ср, 10 окт. 2018 г. в 0:09, Corey Lucier : > > We really wish to lean on LLVM link time optimizations. > > The Emscripten docs say . "LLVM LTO is not perfectly stable yet, and can > cause code to behave incorrectly.". > > Does this note still apply? There's nothing saying what particular scenarios > are problematic and I can't find equivalent docs in the LLVM project itself. > > So...are you guys actively discouraging it's use? > > Thanks, > > Corey > > -- > 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 emscripten-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Stability of llvm-lto
We really wish to lean on LLVM link time optimizations. The Emscripten docs say . "LLVM LTO is not perfectly stable yet, and can cause code to behave incorrectly.". Does this note still apply? There's nothing saying what particular scenarios are problematic and I can't find equivalent docs in the LLVM project itself. So...are you guys actively discouraging it's use? Thanks, Corey -- 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 emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
