Bugzilla

I'm doing some exploration of the SpiderMonkey scenario in Bug 1780686.

- Standalone Spidermonkey (jsshell for development team; GJS; SpiderMonkey-on-WASI; etc)
 - The per-module `metrics.yaml` file is very helpful here and generating stubs of metrics is easy with either `glean_parser` or just a very simple parser. These types of yaml translations are common in existing spidermonkey codebase.
 - The basic interface of metric types used by spidermonkey can be shimmed pretty easily in spidermonkey, and while these might eventually be part of FOGNop, it is not a problem for spidermonkey to maintain itself. Since the probes depend on these interfaces, some amount of stability and build testing is already expected.
 - Overall pretty positive

- SpiderMonkey in Gecko
 - When building as part of Gecko, spidermonkey is still first compiled as a library and then linked into Gecko. This means internals of spidermonkey are not actually exposed to Gecko without building API surfaces.
 - Including the current glean metric type headers right now is a no-go because `nsString` files cannot be used outside of gecko internals. The spidermonkey build does not define the required `MOZILLA_INTERNAL_API` options.
 - If I avoid Event metrics, I can use `ifdef MOZILLA_INTERNAL_API` in the FoG headers to get a build working. I also ifdef out the nsIGleanMetric code which is not needed for SpiderMonkey.
 - If adding `ifdef MOZILLA_INTERNAL_API` is reasonable, I do have a working prototype in Bug 1780686 that builds browser and shell. We probably want to iterate on the approach here.
 - Note that this is different from the FOGNop problem and is more of an issue that the FoG API surface doesn't build outside of Gecko, even if the library is linked in later.

I'm doing some exploration of the SpiderMonkey scenario in Bug 1780686.

- Standalone Spidermonkey (jsshell for development team; GJS; SpiderMonkey-on-WASI; etc)
  - The per-module `metrics.yaml` file is very helpful here and generating stubs of metrics is easy with either `glean_parser` or just a very simple parser. These types of yaml translations are common in existing spidermonkey codebase.
  - The basic interface of metric types used by spidermonkey can be shimmed pretty easily in spidermonkey, and while these might eventually be part of FOGNop, it is not a problem for spidermonkey to maintain itself. Since the probes depend on these interfaces, some amount of stability and build testing is already expected.
  - Overall pretty positive

- SpiderMonkey in Gecko
  - When building as part of Gecko, spidermonkey is still first compiled as a library and then linked into Gecko. This means internals of spidermonkey are not actually exposed to Gecko without building API surfaces.
  - Including the current glean metric type headers right now is a no-go because `nsString` files cannot be used outside of gecko internals. The spidermonkey build does not define the required `MOZILLA_INTERNAL_API` options.
  - If I avoid Event metrics, I can use `ifdef MOZILLA_INTERNAL_API` in the FoG headers to get a build working. I also ifdef out the nsIGleanMetric code which is not needed for SpiderMonkey.
  - If adding `ifdef MOZILLA_INTERNAL_API` is reasonable, I do have a working prototype in Bug 1780686 that builds browser and shell. We probably want to iterate on the approach here.
  - Note that this is different from the FOGNop problem and is more of an issue that the FoG API surface doesn't build outside of Gecko, even if the library is linked in later.