Hi, I'm revisiting the topic of --enable-shared-js for Gecko builds for different reasons than the one that started this thread.
On Mon, Sep 24, 2018 at 08:24:43AM -0400, Boris Zbarsky wrote: > My use case for it is to be able to use the "exclude samples from library X" > or "collapse library X" tools in profilers (like Instruments) to more easily > break down profiles into "page JS" and "Gecko things". > > That said, I haven't done that very much recently... And my guess nobody has done that since, nor for a while, because the way an attempt to build with --enable-shared-js fails leaves me thinking this has been broken at least since bug 1436179 landed... a year ago. Considering this has apparently been broken for so long, I guess nobody will object to me removing the option for Gecko builds? On Tue, Oct 02, 2018 at 09:29:51AM -0500, Luke Wagner wrote: > (Sorry, I polled #jsapi about this issue back when you first posted and > then forgot to reply with the response.) > > It doesn't seem like any SM devs use --enable-shared-js for their own > development but we do know that various embedders (e.g. GNOME) use the JS > shared library and so we'd like to keep that configuration tested and > working. One hybrid option is thus: > - drop support for building Gecko with --enable-shared-js (avoiding the > symbol conflict issue), but keep --enable-shared-js as a configure option > for JS shell builds > - have at least one tier-1 --enable-shared-js JS shell build on automation > so that we at least keep it working It's worth noting that --enable-shared-js is already the default when building spidermonkey standalone. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
