877937 - build the jseng in c++11 mode when we do that for the rest of the tree

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Trevor Saunders (:tbsaunde)]

it'd be nice to have c++11 stuff there too, and it seems to work locally.

Comment 1

[Trevor Saunders (:tbsaunde)]

Attachment: bug 877937 - build the js engine in c++11 mode when we do that for the rest of the tree

Comment 2

[Jeff Walden [:Waldo]]

Comment on attachment 756300 [details] [diff] [review]
bug 877937 - build the js engine in c++11 mode when we do that for the rest of the tree

This solves the problem of building SpiderMonkey as C++.  But if embedders don't use C++11, and our public headers start using C++11-only features without appropriate ifdefs/macros, we'll break stuff.  And I don't doubt that'll happen pretty quickly, if we let this disconnect occur.  So we should do whatever's necessary to add --std=gnu++0x into the compiler flags that embedders are supposed to use.  That would be done by augmenting the js-config.in script however's necessary, probably changing Makefile.in to do so.

Comment 3

[(not currently active) Ted Mielczarek]

Comment on attachment 756300 [details] [diff] [review]
bug 877937 - build the js engine in c++11 mode when we do that for the rest of the tree

Review of attachment 756300 [details] [diff] [review]:
-----------------------------------------------------------------

I kind of wish this was all in a common m4 file instead of copy and pasted, but it'll do.

Comment 4

[Trevor Saunders (:tbsaunde)]

> I kind of wish this was all in a common m4 file instead of copy and pasted,
> but it'll do.


that would force me to figure out more m4, and besides I need to change the jseng version around some so that we can make the js embedding stuff use -std= when appropriate.  However I think we can make some of this code go away fairly soon.

Comment 5

[Trevor Saunders (:tbsaunde)]

Attachment: make js embeddors build as c++11 when we do

Comment 6

[Trevor Saunders (:tbsaunde)]

Comment on attachment 758907 [details] [diff] [review]
make js embeddors build as c++11 when we do

Waldo is this what you want?

I tested this on a machine with gcc 4.4 and -std=gnu++0x wasn't in the output of js-config --cflags, and on a machine with gcc 4.7 it was.

Comment 7

[Hubert Figuiere [:hub]]

I'd use an .m4 file like the one documented there

http://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_11.html
  
But that's just me.

Also why gnu++0x instead of gnu++11 or non gnu extension version -std=c++11?

Comment 8

[Trevor Saunders (:tbsaunde)]

(In reply to Hubert Figuiere [:hub] from comment #7)
> I'd use an .m4 file like the one documented there
> 
> http://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_11.html
>   
> But that's just me.

see comment 4 (this is just coppying stuff from the main configure until we can kill gcc not in c++11 mode which I think we can do in a couple weeks)

> Also why gnu++0x instead of gnu++11 or non gnu extension version -std=c++11?

its known to work with all the compilers we care about as evidenced by the rest of the tree, and we want the gnu extensions.

Comment 9

[Trevor Saunders (:tbsaunde)]

Attachment: make clang on mac happy part 1

I don't pretend to understand the name lookup rules that make it necessary to fully qualify the class name here, but not qualified is fine for method implementations, but it works so *shrug*

Comment 10

[Trevor Saunders (:tbsaunde)]

Attachment: make clang on mac happy part 2

It seems clang is confused about how it should assign to this type when js::Swap() is called on it at jsgc.cpp:3082.  I don't see what we are getting from this copy constructor so lets just remove it and let the compiler generate it for us.

Comment 11

[Jeff Walden [:Waldo]]

Comment on attachment 761431 [details] [diff] [review]
make clang on mac happy part 1

Review of attachment 761431 [details] [diff] [review]:
-----------------------------------------------------------------

I think we ran into this somewhere else, recently, so this is totally fine.

Comment 12

[Jeff Walden [:Waldo]]

Comment on attachment 761438 [details] [diff] [review]
make clang on mac happy part 2

Review of attachment 761438 [details] [diff] [review]:
-----------------------------------------------------------------

This got added to attempt to fix an OS X bustage, but it didn't work, so I'm fine removing it.

Comment 13

[Trevor Saunders (:tbsaunde)]

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/64e15d90cb92
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/744418835d76
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/56e47c35233e

Comment 14

[Jeff Walden [:Waldo]]

Please add a note to https://developer.mozilla.org/en-US/docs/SpiderMonkey/24 describing these changes, maybe linking to this bug for background.  Thanks!

Comment 15

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/64e15d90cb92
https://hg.mozilla.org/mozilla-central/rev/744418835d76
https://hg.mozilla.org/mozilla-central/rev/56e47c35233e

Comment 17

[Trevor Saunders (:tbsaunde)]

Attachment: bug 877937 - copy the work around to allow clang to build as C++11 to js/src/build/unix/headers/

Comment 18

[Mike Hommey [:glandium]]

Note you need to copy the configure.in bits as well if you want that to work on standalone js builds, instead of relying from the fact that it's inherited from the top level configure.

Comment 19

[Trevor Saunders (:tbsaunde)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c14a1283292e

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c14a1283292e

Comment 22

[Mike Hommey [:glandium]]

Bug 883381 essentially reopens this bug. Yay for non-backout effective backouts.

Comment 23

[Mike Hommey [:glandium]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/af7c55ced80b

Comment 24

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/af7c55ced80b