JSAPI users are used to things breaking. It's a guarantee you can bank
on: if you use a new version of SpiderMonkey, something will be broken.
That would be fine, except no one is in charge of updating the
documentation when things change. The best guide to embedding
SpiderMonkey is my example on github, and I only got it to work by
pestering Mozilla debs on IRC.
https://github.com/Chaircrusher/SpiderMonkeyES6Example
It's also obsolete mere weeks after putting it on github since the
latest & greatest SpiderMonkey ESR has moved on.
If Mozilla is committed to having third parties embed SpiderMonkey,
making documentations updates a priority would be a great first step.
On 08/28/2018 09:52 PM, Jeff Walden wrote:
It's a long-term SpiderMonkey goal to break up jsapi.h into separate, small
headers. jsapi.h is *maybe* convenient in that it's one #include, but that
also means compiling SpiderMonkey is super-slow when that file is touched
(which is often).
I just took a notable step in that direction, that probably breaks every JSAPI user. :-)
Specifically, all main-thread compilation/evaluation APIs are now in
"js/CompilationAndEvaluation.h", and the definition of JS::SourceBufferHolder (needed for
many compilation APIs) is now in "js/SourceBufferHolder.h" -- and *neither header is
#include'd in jsapi.h*.
I didn't change API signatures: existing code should work again after you fix
your #includes.
We have no time line for when jsapi.h will be fully broken up, or into what
smaller headers it'll be broken. But it's going to keep happening, and when I
see *removals* of API from jsapi.h into headers not #include'd within it, such
that existing users depending on the one-stop shop will break, I'll try to make
a note in mdt.js-engine and mdt.js-engine.internals.
Jeff
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
