[chromium-dev] Are Web Sockets supposed to work now?
The last comment to the issue 12497 says that basic Web Socket feature has been implemented. Here's the address: http://code.google.com/p/chromium/issues/detail?id=12497 I tried creating a WebSocket-object as described on http://websockets.org/about.html. I assigned functions to onopen, onmessage and onclose. I only got onclose working. It doesn't make sense sending anything without having an open socket, but I tried the send-method just to have tried it. I got INVALID_STATE_ERR in the console when executing send on a connection that wasn't not open, and according to the current Web Sockets working draft, that's how it should be. I tried running Kaazing Open Gateway locally and connected to the various ws://-protocols. I also did an attempt at using node.js to create a minimal TCP server. Nothing that I did triggered onopen. My use case is very simple right now. I only want to send and receive something over a Web Sockets-socket to verify that it works. -- Best regards, Alexander Teinum -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Are Web Sockets supposed to work now?
I forgot (again) to mention that I use 64-bit Linux. It's tested with mode set to release. On Wed, Nov 11, 2009 at 1:00 PM, Alexander Teinum atei...@gmail.com wrote: The last comment to the issue 12497 says that basic Web Socket feature has been implemented. Here's the address: http://code.google.com/p/chromium/issues/detail?id=12497 I tried creating a WebSocket-object as described on http://websockets.org/about.html. I assigned functions to onopen, onmessage and onclose. I only got onclose working. It doesn't make sense sending anything without having an open socket, but I tried the send-method just to have tried it. I got INVALID_STATE_ERR in the console when executing send on a connection that wasn't not open, and according to the current Web Sockets working draft, that's how it should be. I tried running Kaazing Open Gateway locally and connected to the various ws://-protocols. I also did an attempt at using node.js to create a minimal TCP server. Nothing that I did triggered onopen. My use case is very simple right now. I only want to send and receive something over a Web Sockets-socket to verify that it works. -- Best regards, Alexander Teinum -- Best regards, Alexander Teinum -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Are Web Sockets supposed to work now?
What code did you try? Which websocket server do you use? Here's the code that I played around with: http://pastebin.com/f47210090 I tried to connect to ws://www.websocket.org, which is an address mentioned on the website. If it's up and running, then it's probably either set up with Kaazing Open Gateway or Kaazing Enterprise Gateway, since the website is run by Kaazing. AFAIK, it works fine with pywebsocket (code.google.com/p/pywebsocket), and sample code of tic-tac-toe at http://damowmow.com/playground/demos/websocket/ Thanks, I didn't know about pywebsocket. I'll see if I can get it working. On Wed, Nov 11, 2009 at 1:19 PM, Fumitoshi Ukai (鵜飼文敏) u...@google.com wrote: On Wed, Nov 11, 2009 at 9:00 PM, Alexander Teinum atei...@gmail.com wrote: The last comment to the issue 12497 says that basic Web Socket feature has been implemented. Here's the address: http://code.google.com/p/chromium/issues/detail?id=12497 I tried creating a WebSocket-object as described on http://websockets.org/about.html. I assigned functions to onopen, onmessage and onclose. I only got onclose working. What code did you try? Which websocket server do you use? AFAIK, it works fine with pywebsocket (code.google.com/p/pywebsocket), and sample code of tic-tac-toe at http://damowmow.com/playground/demos/websocket/ -- ukai It doesn't make sense sending anything without having an open socket, but I tried the send-method just to have tried it. I got INVALID_STATE_ERR in the console when executing send on a connection that wasn't not open, and according to the current Web Sockets working draft, that's how it should be. I tried running Kaazing Open Gateway locally and connected to the various ws://-protocols. I also did an attempt at using node.js to create a minimal TCP server. Nothing that I did triggered onopen. My use case is very simple right now. I only want to send and receive something over a Web Sockets-socket to verify that it works. -- Best regards, Alexander Teinum -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Best regards, Alexander Teinum -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: test_shell performance is bad compared to Chromium
Test shell covers layer 3 and down. Unfortunately, all the performance you like is in layer 2. Thanks for clarifying. I have had some time to think about what you guys have been saying, and I have decided to start out with kiosk mode. At some point in the future I will probably want to remove what I don't need. It will require some work, but if it were easy then your job would be boring. :) I'm getting used to not having a boring job. On Tue, Nov 10, 2009 at 7:26 PM, Evan Martin e...@chromium.org wrote: On Thu, Nov 5, 2009 at 3:34 PM, Alexander Teinum atei...@gmail.com wrote: I want to make it clear, and it might be obvious by now, but test_shell isn't interesting to me. I just want the fastest browser engine that I can get. What makes Chromium different than WebKitGTK+ for my project, is that Chromium renders the GTK stuff correctly with CSS transformations. It's also snappier. Conceptually Chrome is a bunch of layers, from top to bottom 1) chrome+ui junk 2) multiprocess rendering 3) webkit API 4) webkit Test shell covers layer 3 and down. Unfortunately, all the performance you like is in layer 2. We don't have a simple place to cut for that; however, since Chrome and test_shell are both just clients of the WebKit API, you could write your own client (like test_shell) and then copy the performant bits out of Chrome. It will require some work, but if it were easy then your job would be boring. :) -- Best regards, Alexander Teinum -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] test_shell performance is bad compared to Chromium
For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Alexander On Thu, Nov 5, 2009 at 10:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
This is exactly what i want. Thanks! I'll see if I can make it work. Alexander On Thu, Nov 5, 2009 at 10:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Alexander On Thu, Nov 5, 2009 at 10:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
test_shell doesn't implement the fast painting for one. Is the scrolling performance the problem that you're seeing? Yes, I perceive the scolling, CSS scale-transformations on the iframes, and moving the iframes around as the biggest performance problems. All of these issues might be related to that? On Thu, Nov 5, 2009 at 10:47 PM, Adam Langley a...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. test_shell doesn't implement the fast painting for one. Is the scrolling performance the problem that you're seeing? AGL -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
Maybe star http://crbug.com/23145 to express your interest. That might motivate mhm to get this ready for checkin. Done! :) Alexander On Thu, Nov 5, 2009 at 11:02 PM, Nico Weber tha...@chromium.org wrote: Maybe star http://crbug.com/23145 to express your interest. That might motivate mhm to get this ready for checkin. On Thu, Nov 5, 2009 at 1:58 PM, Alexander Teinum atei...@gmail.com wrote: This is exactly what i want. Thanks! I'll see if I can make it work. Alexander On Thu, Nov 5, 2009 at 10:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Alexander On Thu, Nov 5, 2009 at 10:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Sorry Dirk, I could have said why I don't think it's an optimal solution. I think it's fine to have components that are not used, as long as they don't eat resources or get in the way. The status bar gets in the way for my project while in fullscreen. There's also a 1 pixel border on top that I don't want. I don't want the user to trigger any of the Chromium UI with the keyboard. A --fullscreen switch could also work. Without being a kiosk computer expert, I'd think that kiosk mode communicates that the program should be restricted. It might prevent the user from going back from fullscreen or exiting Chromium. On Thu, Nov 5, 2009 at 11:06 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Definitely do not attempt to use test_shell for anything other than testing purposes. It is not, and should not be, a usable or performant product, and as Dirk mentioned, we may eliminate it completely in the future. PK -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
Whops, I'm saying sorry to Dirk and replying to Peter. Sorry to both of you. ;) On Thu, Nov 5, 2009 at 11:24 PM, Alexander Teinum atei...@gmail.com wrote: Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Sorry Dirk, I could have said why I don't think it's an optimal solution. I think it's fine to have components that are not used, as long as they don't eat resources or get in the way. The status bar gets in the way for my project while in fullscreen. There's also a 1 pixel border on top that I don't want. I don't want the user to trigger any of the Chromium UI with the keyboard. A --fullscreen switch could also work. Without being a kiosk computer expert, I'd think that kiosk mode communicates that the program should be restricted. It might prevent the user from going back from fullscreen or exiting Chromium. On Thu, Nov 5, 2009 at 11:06 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Definitely do not attempt to use test_shell for anything other than testing purposes. It is not, and should not be, a usable or performant product, and as Dirk mentioned, we may eliminate it completely in the future. PK -- Best regards/Med vennlig hilsen, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. It's in the Linux-version. In BrowserWindowGtk::InitWidgets() there’s this line: gtk_widget_set_size_request(toolbar_border_, -1, 1); I changed it into: gtk_widget_set_size_request(toolbar_border_, -1, -1); That got rid of it, but that also removes it from the normal mode, where it should be. It's the line between the web browser view and the toolbars above. On Thu, Nov 5, 2009 at 11:33 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. I thought this was intentionally abandoned because it was growing out of control. That's what I was alluding to before. On Thu, Nov 5, 2009 at 2:24 PM, Alexander Teinum atei...@gmail.com wrote: There's also a 1 pixel border on top that I don't want. I don't want the user to trigger any of the Chromium UI with the keyboard. What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. PK -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
Sure. I'm not into the patching process yet, but give me a couple of days, and I'll try to get it fixed. Alexander On Thu, Nov 5, 2009 at 11:48 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 2:46 PM, Alexander Teinum atei...@gmail.com wrote: What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. It's in the Linux-version. In BrowserWindowGtk::InitWidgets() there’s this line: gtk_widget_set_size_request(toolbar_border_, -1, 1); I changed it into: gtk_widget_set_size_request(toolbar_border_, -1, -1); That got rid of it, but that also removes it from the normal mode, where it should be. It's the line between the web browser view and the toolbars above. If you can provide a patch to do the right thing (no line in fullscreen mode), that'd be awesome, otherwise can you file a bug about this? PK -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
I want to make it clear, and it might be obvious by now, but test_shell isn't interesting to me. I just want the fastest browser engine that I can get. What makes Chromium different than WebKitGTK+ for my project, is that Chromium renders the GTK stuff correctly with CSS transformations. It's also snappier. Making the rendering part of Chromium easier to use for open source project would benefit projects such as mine or uzbl for instance. uzbl is a WebKitGTK+ browser that is controlled similar to Vim. I realize that CEF is an effort at making it easier to embed Chromium, but if it's based on test_shell, then well... what about the platform optimalizations? Are they easy to get into CEF, or does it have to play catch-up? On Fri, Nov 6, 2009 at 12:21 AM, Mohamed Mansour m...@chromium.org wrote: On Thu, Nov 5, 2009 at 5:33 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. I thought this was intentionally abandoned because it was growing out of control. That's what I was alluding to before. Not entirely abandoned, true it was getting out of control and that is why I stopped to take a step back. Technically it should be what I did for patch set one, which is just fullscreen + no statusbar. That is basically what the functionality is. I will continue working on it tonight. - Mohamed Mansour -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Compiler warning with Arch Linux and make
Success. Adding 'remove_webcore_debug_symbols' to include.gypi probably solved my problem (although I did a debug build now). This is the first time that I have had success compiling Chromium in Arch Linux with make. And it's also the first time that I have gotten a debug build working in Arch Linux. I don't know if it makes any difference, but I built with V=1. On Sat, Oct 31, 2009 at 3:55 PM, Alexander Teinum atei...@gmail.com wrote: I'm trying to compile Chromium on 64-bit Arch Linux. It did work fine with SCons in release mode, but it seems like make is going to replace SCons from what I have read in the recent discussions. I have had a lot of pain compiling Chromium in general, because of gperf, generated code, strict aliasing etc. I have still not found a solution to those problems. But it did compile with SCons when mode was set to release. I have created ~/.gyp/include.gypi, pasted in the settings from the wiki, and set these variables: export GYP_GENERATORS=make export GYP_DEFINES=target_arch=x64 And finally: gclient sync make chrome BUILDTYPE=Release Here's what happens with any recent, green build: CXX(target) out/Release/obj.target/renderer/chrome/renderer/localized_error.o CXX(target) out/Release/obj.target/renderer/chrome/renderer/notification_provider.o CXX(target) out/Release/obj.target/renderer/chrome/renderer/print_web_view_helper.o CXX(target) out/Release/obj.target/renderer/chrome/renderer/print_web_view_helper_linux.o CXX(target) out/Release/obj.target/renderer/chrome/renderer/render_process.o CXX(target) out/Release/obj.target/renderer/chrome/renderer/render_thread.o cc1plus: warnings being treated as errors In file included from ./chrome/renderer/renderer_webkitclient_impl.h:9, from chrome/renderer/render_thread.cc:45: ./chrome/renderer/websharedworkerrepository_impl.h:10: error: declaration ‘struct WebKit::WebSharedWorker’ does not declare anything make: *** [out/Release/obj.target/renderer/chrome/renderer/render_thread.o] Error 1 Can anyone point me in the right direction? -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Compiler warning with Arch Linux and make
I'm trying to compile Chromium on 64-bit Arch Linux. It did work fine with SCons in release mode, but it seems like make is going to replace SCons from what I have read in the recent discussions. I have had a lot of pain compiling Chromium in general, because of gperf, generated code, strict aliasing etc. I have still not found a solution to those problems. But it did compile with SCons when mode was set to release. I have created ~/.gyp/include.gypi, pasted in the settings from the wiki, and set these variables: export GYP_GENERATORS=make export GYP_DEFINES=target_arch=x64 And finally: gclient sync make chrome BUILDTYPE=Release Here's what happens with any recent, green build: CXX(target) out/Release/obj.target/renderer/chrome/renderer/localized_error.o CXX(target) out/Release/obj.target/renderer/chrome/renderer/notification_provider.o CXX(target) out/Release/obj.target/renderer/chrome/renderer/print_web_view_helper.o CXX(target) out/Release/obj.target/renderer/chrome/renderer/print_web_view_helper_linux.o CXX(target) out/Release/obj.target/renderer/chrome/renderer/render_process.o CXX(target) out/Release/obj.target/renderer/chrome/renderer/render_thread.o cc1plus: warnings being treated as errors In file included from ./chrome/renderer/renderer_webkitclient_impl.h:9, from chrome/renderer/render_thread.cc:45: ./chrome/renderer/websharedworkerrepository_impl.h:10: error: declaration ‘struct WebKit::WebSharedWorker’ does not declare anything make: *** [out/Release/obj.target/renderer/chrome/renderer/render_thread.o] Error 1 Can anyone point me in the right direction? -- Best regards, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
