[PATCH v3 1/4] change mozjs interface module to c++

[Jeremy Linton]

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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/polkit-devel
>