Hi,

On 12/12/2016 09:57 AM, Colin Walters wrote:


On Mon, Dec 12, 2016, at 10:48 AM, Jeremy Linton wrote:
Hi,

On 12/12/2016 09:18 AM, Colin Walters wrote:
On Fri, Aug 26, 2016, at 02:01 PM, Jeremy Linton wrote:
The JSAPI is now a full C++ interface. Convert the polkit
to JavaScript interface module to C++ compilation in order to
support newer versions of spidermonkey.

Ok, https://bugs.freedesktop.org/show_bug.cgi?id=97763 was
fixed, so I went ahead and pushed this one.  Thanks!

Thanks, that is great!

Only now, gnome has patches in flight to move to mozjs31. So I should
probably roll another patch set for mozjs31 (or 38) depending on where
they land. Since the goal is to cut down on the number of legacy mozjs
versions the distro's are shipping.

Unconditional porting?  Maybe...we should have a discussion
here about whether we can do that or whether we'll need
to support multiple again.

Concretely, we just have mozjs24 in CentOS7 stable right now.  Now,
we do have some ability to change that for future versions, and we
likely will, but I'm not sure whether having a single version in polkit
git is realistic.

Yes, there will likely have to be some careful timing, or support for multiple version.


Maybe one approach we could try is, rather than #ifdef, pull up
some of the common JS-indpendent bits like `utils_spawn()` into
a jsauthorityutils.c, that can be called by 
polkitbackendjsauthority-mozjs24.cpp,
polkitbackendjsauthority-mozjs31.cpp, etc.

There are a fair number of choices besides #ifdefs. Being C++, the whole thing could be buried behind an abstract class, or for that matter dynamically loaded. What the world really needs is a mozjs "thunk" library that provides a stable API for people to use <half joking> cross mozjs versions...

I've got a few more of these mozjs version patches floating around for other projects. So, I don't intend to take another look at polkit until I get some of those other projects straightened out. Which from the looks of it will take some time.



If we go this route it'd make it easier for downstreams to carry
the maintenance burden of older ones, or conversely port to
a newer one without a lot of patch conflicts.
_______________________________________________
polkit-devel mailing list
polkit-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/polkit-devel


_______________________________________________
polkit-devel mailing list
polkit-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/polkit-devel

Reply via email to