Send connman mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."


Today's Topics:

   1. Re: [PATCH v2] Port pacrunner to mozjs24 (Jeremy Linton)
   2. Re: [PATCH v2] Pull pacrunner forward to mozjs24 (David Woodhouse)
   3. Re: [PATCH v2] Pull pacrunner forward to mozjs24 (Jeremy Linton)
   4. Re: [PATCH v2] Pull pacrunner forward to mozjs24 (David Woodhouse)


----------------------------------------------------------------------

Message: 1
Date: Thu, 8 Sep 2016 16:02:29 -0500
From: Jeremy Linton <[email protected]>
To: [email protected]
Subject: Re: [PATCH v2] Port pacrunner to mozjs24
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed

Ping?

Has anyone had a chance to look at this or try it out?

Thanks,


On 08/31/2016 02:36 PM, Jeremy Linton wrote:
> This patch moves pacrunner to mozjs24. This is still
> a little behind the times, but gnome/etc are using mozjs24
> so the distro's are on the hook for supporting it.
>
> v1->v2 Change automake script so that --disable-mozjs doesn't require
>  pacrunner to depend on the C++ support libraries.
>
> Jeremy Linton (1):
>   Pull pacrunner forward to mozjs24
>
>  Makefile.am                    | 20 +++++++++++++-------
>  configure.ac                   |  4 ++--
>  plugins/{mozjs.c => mozjs.cpp} | 36 +++++++++++++++++++-----------------
>  3 files changed, 34 insertions(+), 26 deletions(-)
>  rename plugins/{mozjs.c => mozjs.cpp} (82%)
>



------------------------------

Message: 2
Date: Thu, 08 Sep 2016 22:15:59 +0100
From: David Woodhouse <[email protected]>
To: Jeremy Linton <[email protected]>, [email protected]
Subject: Re: [PATCH v2] Pull pacrunner forward to mozjs24
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

On Wed, 2016-08-31 at 14:36 -0500, Jeremy Linton wrote:
> Mozjs185 is getting really old and unsupported. Newer versions
> of the mozjs JSAPI are C++ based. Start the conversion to more recent
> JSAPI's by updating pacrunner to use mozjs24 which is a common version
> being used by a number of distributions. It also happens to be the first
> C++ only version of JSAPI.

In file included from /usr/include/mozjs-24/jsapi.h:24:0,
?????????????????from plugins/mozjs.cpp:34:
/usr/include/mozjs-24/jspubtd.h:370:50: warning: offsetof within 
non-standard-layout type ?js::PerThreadDataFriendFields::RuntimeDummy? is 
undefined [-Winvalid-offsetof]
?????static const size_t RuntimeMainThreadOffset = offsetof(RuntimeDummy, 
mainThread);

Also, why call it 'mozjs.cpp' when the v8 one is call 'v8.cc'? 
If you want to *rename* v8.cc to v8.cpp then I'll have no objection to
that, but please don't be inconsistent.

I'm sure how much the resulting comments in Makefile.am make sense if
you read the file rather than purely looking at the history. Your mozjs
comments come *above* the v8 one I'd already added, and it ends up
reading...

# similar to v8 if mozjs isn't enabled then
# try to avoid using g++ by building a library
# This is a bit funny because at first sight you would think that
# the #if MOZJS would keep the builtin_sources from affecting the automake
# choice of linker, but it doesn't.
...
# If we compile this into a v8.a library first, then autohell
# won't use g++ to link pacrunner. And thus won't end up linking
# against libstdc++ even in the builds where V8 is disabled.

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: 
<http://lists.01.org/pipermail/connman/attachments/20160908/dfad27ab/attachment-0001.bin>

------------------------------

Message: 3
Date: Thu, 8 Sep 2016 17:03:06 -0500
From: Jeremy Linton <[email protected]>
To: David Woodhouse <[email protected]>, [email protected]
Subject: Re: [PATCH v2] Pull pacrunner forward to mozjs24
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

        Thanks for taking a look at this, more below./

On 09/08/2016 04:15 PM, David Woodhouse wrote:
> On Wed, 2016-08-31 at 14:36 -0500, Jeremy Linton wrote:
>> Mozjs185 is getting really old and unsupported. Newer versions
>> of the mozjs JSAPI are C++ based. Start the conversion to more recent
>> JSAPI's by updating pacrunner to use mozjs24 which is a common version
>> being used by a number of distributions. It also happens to be the first
>> C++ only version of JSAPI.
>
> In file included from /usr/include/mozjs-24/jsapi.h:24:0,
>                  from plugins/mozjs.cpp:34:
> /usr/include/mozjs-24/jspubtd.h:370:50: warning: offsetof within 
> non-standard-layout type ?js::PerThreadDataFriendFields::RuntimeDummy? is 
> undefined [-Winvalid-offsetof]
>      static const size_t RuntimeMainThreadOffset = offsetof(RuntimeDummy, 
> mainThread);

I believe this is a recent GCC warning complaining about a offsetof a 
struct with a parent class, so its not strictly POD (at least that is 
the way I read it). This is mozjs issue, not related to anything in 
pacrunner, so there isn't any way for pacrunner to "fix" it outside of 
suppressing the warning, which is probably valid in this case.

Should I still suppress it?


>
> Also, why call it 'mozjs.cpp' when the v8 one is call 'v8.cc'?
> If you want to *rename* v8.cc to v8.cpp then I'll have no objection to
> that, but please don't be inconsistent.

Well the .cpp was more a reflection of mozjs's naming convention rather 
than v8s, which I looked at only as part of the v2 link rework. I will 
rename it to .cc.


>
> I'm sure how much the resulting comments in Makefile.am make sense if
> you read the file rather than purely looking at the history. Your mozjs
> comments come *above* the v8 one I'd already added, and it ends up
> reading...

<shrug> Since it came first I thought it might be best to clone your 
comment for mozjs, but then I spent a few hours trying to figure out why 
things conceptually missing from the build, were still affecting the 
linker choice. I learned a few more things about automake I didn't 
really want to know...

Rather than mess with your comment, i'm just going to drop the new one. 
Is that ok?




>
> # similar to v8 if mozjs isn't enabled then
> # try to avoid using g++ by building a library
> # This is a bit funny because at first sight you would think that
> # the #if MOZJS would keep the builtin_sources from affecting the automake
> # choice of linker, but it doesn't.
> ...
> # If we compile this into a v8.a library first, then autohell
> # won't use g++ to link pacrunner. And thus won't end up linking
> # against libstdc++ even in the builds where V8 is disabled.
>



------------------------------

Message: 4
Date: Thu, 08 Sep 2016 23:10:24 +0100
From: David Woodhouse <[email protected]>
To: Jeremy Linton <[email protected]>, [email protected]
Subject: Re: [PATCH v2] Pull pacrunner forward to mozjs24
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

On Thu, 2016-09-08 at 17:03 -0500, Jeremy Linton wrote:
> I believe this is a recent GCC warning complaining about a offsetof a?
> struct with a parent class, so its not strictly POD (at least that is?
> the way I read it). This is mozjs issue, not related to anything in?
> pacrunner, so there isn't any way for pacrunner to "fix" it outside of?
> suppressing the warning, which is probably valid in this case.

Except perhaps by moving to a newer version of mozjs which *is* valid
C++? I concede I make that suggestion with no real clue about all the
various different versions that seem to be simultaneously available...

> Should I still suppress it?

Well, I already had to fix harmless duktape 'unused function' warnings
because we need -Werror builds to work. So I suspect you'll need to do
*something*.

> Rather than mess with your comment, i'm just going to drop the new one.?
> Is that ok?

Well, then the comment occurs on the *second* instance of that within
the Makefile.am, which still isn't ideal. But OK, if you must.

--?
dwmw2


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: 
<http://lists.01.org/pipermail/connman/attachments/20160908/a8a1d854/attachment.bin>

------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman


------------------------------

End of connman Digest, Vol 11, Issue 11
***************************************

Reply via email to