info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
XPT files shouldn't be added to package-manifest.in any more
57 views
Skip to first unread message
Andrew McCreight
Apr 5, 2018, 11:00:04 AM4/5/18
to Firefox Dev, dev-platform
I recently landed bug 1438688, which makes it so that we don't ship XPT
files any more, so they don't need to be added to a package-manifest.in
file. (Instead, the XPT information is compiled into the binary.) I think
it'll give you an error if you add it anyways, but I haven't tested it. We
still use XPT files during the build process, so you'll see them appear in
your build log spam as usual.
Andrew
files any more, so they don't need to be added to a package-manifest.in
file. (Instead, the XPT information is compiled into the binary.) I think
it'll give you an error if you add it anyways, but I haven't tested it. We
still use XPT files during the build process, so you'll see them appear in
your build log spam as usual.
Andrew
Gijs Kruitbosch
Apr 18, 2018, 1:54:16 PM4/18/18
to Andrew McCreight, Firefox Dev
Err, so it seems a side-effect of this (which wasn't very obvious to me
when this was posted) is that it's now no longer possible to change a
.idl file for a JS component in an artifact build and have it "work".
Specifically, I ran into this when changing the return type of an extant
idl method for nsBlocklistService.js from `unsigned long` to `jsval`
(making the method async). I spent a good few hours being puzzled as to
how callsites using `await` were getting 0 when the callee was
(asynchronously) returning non-zero things, and why the logs from the
caller and callee were out of order. Turns out, xpconnect and friends
will happily silently convert things (in this case, a Promise object) to
match the declared return type (ending up with NaN/0).
TL;DR: the effect on artifact build users seems pretty unfortunate.
Given that we're also not supposed to be making new JS-implemented
webidl things, what's the long-term plan for artifact build support for
changing JS-implemented interfaces?
~ Gijs
when this was posted) is that it's now no longer possible to change a
.idl file for a JS component in an artifact build and have it "work".
Specifically, I ran into this when changing the return type of an extant
idl method for nsBlocklistService.js from `unsigned long` to `jsval`
(making the method async). I spent a good few hours being puzzled as to
how callsites using `await` were getting 0 when the callee was
(asynchronously) returning non-zero things, and why the logs from the
caller and callee were out of order. Turns out, xpconnect and friends
will happily silently convert things (in this case, a Promise object) to
match the declared return type (ending up with NaN/0).
TL;DR: the effect on artifact build users seems pretty unfortunate.
Given that we're also not supposed to be making new JS-implemented
webidl things, what's the long-term plan for artifact build support for
changing JS-implemented interfaces?
~ Gijs
Boris Zbarsky
Apr 18, 2018, 3:15:31 PM4/18/18
to
On 4/18/18 1:54 PM, Gijs Kruitbosch wrote:
> Err, so it seems a side-effect of this (which wasn't very obvious to me
> when this was posted) is that it's now no longer possible to change a
> ..idl file for a JS component in an artifact build and have it "work".
> Err, so it seems a side-effect of this (which wasn't very obvious to me
> when this was posted) is that it's now no longer possible to change a
So to be clear, this is a case in which you have an IDL-declared thing
that is only implemented in JS _and_ only called into from JS, right?
> Given that we're also not supposed to be making new JS-implemented
> webidl things, what's the long-term plan for artifact build support for
> changing JS-implemented interfaces?
using an IDL-declared interface at all, if I might ask?
-Boris
Kris Maglione
Apr 18, 2018, 3:27:40 PM4/18/18
to Boris Zbarsky, dev-pl...@lists.mozilla.org
consumers. The JS-only parts wound up getting glommed onto the
XPIDL interface over time. I'd already suggested we fix that
before I realized it was the cause of this problem.
Boris Zbarsky
Apr 18, 2018, 3:34:21 PM4/18/18
to
On 4/18/18 3:27 PM, Kris Maglione wrote:
> Legacy. The blocklist service is ancient, and has some C++ consumers.
> The JS-only parts wound up getting glommed onto the XPIDL interface over
> time. I'd already suggested we fix that before I realized it was the
> cause of this problem.
OK. In that case, I think the long-term plan Gijs is asking about
> Legacy. The blocklist service is ancient, and has some C++ consumers.
> The JS-only parts wound up getting glommed onto the XPIDL interface over
> time. I'd already suggested we fix that before I realized it was the
> cause of this problem.
should be "don't use XPIDL for calls that are known to always be
JS-to-JS"...
-Boris
0 new messages