[chromium-dev] Chrome.exe Versioning
Is the zero versioned executable intentional?I mean, when you look at the properties for chrome.exe, it always has 0.0.0.0 as a version. Now, I know the executable is not always changing (f I understand correctly, most of the changes are in the DLL), so perhaps it should have its own versioning system, though I think the regular versioning system is sufficient. Or no one cares about it, anyway and that is why it is always 0.0.0.0. :) ☆PhistucK --~--~-~--~~~---~--~~ 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: changing chrome_exe to chrome, converting chrome.exe to gyp
This also broke building from the command line. I usually never open Visual Studio as an IDE. I build on the command line with something like: devenv chrome\\chrome.sln /Build release /Project test_shell It looks like project names like test_shell now have complicated names like test_shell (webkit\tools\test_shell\test_shell), and I haven't been able to manage supplying those on the command line. Is there a way we can get back our nice project names test_shell, chrome, etc? On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkusscher...@chromium.org wrote: Here's a quick example: 1) Delete whole Debug directory 2) gclient runhooks --force 3) Set test_shell as startup project 4) Hit F5 Sample output of things that shouldn't be dependencies (mostly because they're other executables) sandbox (sandbox\sandbox) - Debug Win32 chrome_dll - Debug Win32 net_perftests - Debug Win32 base_unittests - Debug Win32 net_unittests - Debug Win32 v8_shell - Debug Win32 mini_installer - Debug Win32 test_support_unit - Debug Win32 test_support_ui - Debug Win32 codesighs (third_party\codesighs\codesighs) - Debug Win32 automated_ui_tests - Debug Win32 memory_test - Debug Win32 activex_test_control - Debug Win32 On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson bradnel...@google.com wrote: Andrew, can you give an example of something that built that shouldn't have for test_shell? Maybe we have some overspecified dependencies as well. -BradN On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus scher...@chromium.org wrote: I'll see if I can repro this again before filing a bug, but similar to what Daniel and John reported, when I right click on test_shell and say Build it builds the minimal set required to fully build+link test_shell.exe However when I set test_shell as the start-up project and launch the debugger, Visual Studio warns that every other project in chrome.sln must be built before running (not true!). Is there a difference in build vs. runtime dependencies? Andrew On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote: All-- When you notice missing dependencies, pleased add them to the necessary .gyp file(s)! One of the main reasons we've been trying to land all this stuff is so that tracking down all these pieces isn't single-threaded through one person (or two). If you're not comfortable making the change yourself, then please file a bug so the dependency problems get tracked and fixed in an organized fashion. Re: unnecessary rebuilds: please file bugs so they don't get lost. Please include the target you were building, and the the libs/targets that were rebuilt unnecessarily. You don't have to be exhaustive about the list, it's more important here that at least some information gets collected and doesn't languish on the ML or get dropped on the floor. I'm working on a buildbot script that will test for missing dependencies by building every target from scratch individually, and will then test for unnecessary rebuilds by rebuilding each target after no updates. That's been taking a back seat to just getting the conversion completed, but I've accelerated my work on it as we wind down to the last few targets. --SK On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.org wrote: Yeah it happened to me before as well, I just figured I'd complain now.. Note another missing dependency is on crash_service.exe , npapi_layout_test_plugin, and npapi_test_plugin btw just to be clear, these are missing dependencies on ui_tests. On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.com wrote: I actually had this problem _before_ this change. Guess I should have brought it up, but I figured it was just something funny on my system. On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.org wrote: +1 this is affecting a lot of people. On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.com wrote: I notice that when I load chrome.sln and do a build, not all the dependencies are built anymore. For instance, theme_dll isn't built (not listed in the proj deps), is this expected? On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote: Okay, it looks like this change is sticking, at least until someone discovers Yet Another Unintended Side Effect. So heed the warnings in the previous message, quoted below. Git users on Linux: this requires an update to gyp to work properly, so make sure you gclient sync after you git pull, or whatever the right combination of commands is. If you see Python stack traces from gyp accompanied by complaints about looking up a Dir as a File, make sure the tools/gyp subdirectory is at r521. --SK On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
Additionally it seems like I'm getting no parallelism. I checked my visual studio settings and everything seems fine. Attached is a screenshot of how my CPU usage has looked for the entire processing of building test_shell (from chrome.sln). -- dean On Fri, Jun 19, 2009 at 12:10 PM, Dean McNameede...@chromium.org wrote: This also broke building from the command line. I usually never open Visual Studio as an IDE. I build on the command line with something like: devenv chrome\\chrome.sln /Build release /Project test_shell It looks like project names like test_shell now have complicated names like test_shell (webkit\tools\test_shell\test_shell), and I haven't been able to manage supplying those on the command line. Is there a way we can get back our nice project names test_shell, chrome, etc? On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkusscher...@chromium.org wrote: Here's a quick example: 1) Delete whole Debug directory 2) gclient runhooks --force 3) Set test_shell as startup project 4) Hit F5 Sample output of things that shouldn't be dependencies (mostly because they're other executables) sandbox (sandbox\sandbox) - Debug Win32 chrome_dll - Debug Win32 net_perftests - Debug Win32 base_unittests - Debug Win32 net_unittests - Debug Win32 v8_shell - Debug Win32 mini_installer - Debug Win32 test_support_unit - Debug Win32 test_support_ui - Debug Win32 codesighs (third_party\codesighs\codesighs) - Debug Win32 automated_ui_tests - Debug Win32 memory_test - Debug Win32 activex_test_control - Debug Win32 On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson bradnel...@google.com wrote: Andrew, can you give an example of something that built that shouldn't have for test_shell? Maybe we have some overspecified dependencies as well. -BradN On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus scher...@chromium.org wrote: I'll see if I can repro this again before filing a bug, but similar to what Daniel and John reported, when I right click on test_shell and say Build it builds the minimal set required to fully build+link test_shell.exe However when I set test_shell as the start-up project and launch the debugger, Visual Studio warns that every other project in chrome.sln must be built before running (not true!). Is there a difference in build vs. runtime dependencies? Andrew On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote: All-- When you notice missing dependencies, pleased add them to the necessary .gyp file(s)! One of the main reasons we've been trying to land all this stuff is so that tracking down all these pieces isn't single-threaded through one person (or two). If you're not comfortable making the change yourself, then please file a bug so the dependency problems get tracked and fixed in an organized fashion. Re: unnecessary rebuilds: please file bugs so they don't get lost. Please include the target you were building, and the the libs/targets that were rebuilt unnecessarily. You don't have to be exhaustive about the list, it's more important here that at least some information gets collected and doesn't languish on the ML or get dropped on the floor. I'm working on a buildbot script that will test for missing dependencies by building every target from scratch individually, and will then test for unnecessary rebuilds by rebuilding each target after no updates. That's been taking a back seat to just getting the conversion completed, but I've accelerated my work on it as we wind down to the last few targets. --SK On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.org wrote: Yeah it happened to me before as well, I just figured I'd complain now.. Note another missing dependency is on crash_service.exe , npapi_layout_test_plugin, and npapi_test_plugin btw just to be clear, these are missing dependencies on ui_tests. On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.com wrote: I actually had this problem _before_ this change. Guess I should have brought it up, but I figured it was just something funny on my system. On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.org wrote: +1 this is affecting a lot of people. On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.com wrote: I notice that when I load chrome.sln and do a build, not all the dependencies are built anymore. For instance, theme_dll isn't built (not listed in the proj deps), is this expected? On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote: Okay, it looks like this change is sticking, at least until someone discovers Yet Another Unintended Side Effect. So heed the warnings in the previous message, quoted below. Git users on Linux: this requires an update to gyp to work properly, so make sure
[chromium-dev] Running Cocoa in the renderer and bug 14609
http://crbug.com/14609 ... In the renderer we need to run Cocoa on a non-main thread. To pump windowserver events we need to pump on the main thread. And when we do so timers and notifications fire, screwing us over. I think the timers and notifications were not fired before, right? In the short term, I think that changing the run loop mode in which we pull events should fix things. I'm trying that out now. In the long term, I think this is yet another reminder about getting Cocoa out of the renderer... :) Avi --~--~-~--~~~---~--~~ 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: Running Cocoa in the renderer and bug 14609
On Fri, Jun 19, 2009 at 6:44 AM, Avi Drissmana...@google.com wrote: In the long term, I think this is yet another reminder about getting Cocoa out of the renderer... :) What do you use Cocoa in the renderer for? Does that include Core Graphics? Or is it just for widget rendering? --~--~-~--~~~---~--~~ 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: Running Cocoa in the renderer and bug 14609
Core Graphics is a level lower than Cocoa, and as the main way to draw on the Mac would be OK to use. I don't know what we use Cocoa for. I think widget rendering but I could be wrong. Avi On Fri, Jun 19, 2009 at 10:58 AM, Evan Martin e...@chromium.org wrote: On Fri, Jun 19, 2009 at 6:44 AM, Avi Drissmana...@google.com wrote: In the long term, I think this is yet another reminder about getting Cocoa out of the renderer... :) What do you use Cocoa in the renderer for? Does that include Core Graphics? Or is it just for widget rendering? --~--~-~--~~~---~--~~ 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: changing chrome_exe to chrome, converting chrome.exe to gyp
[resend to chromium-dev from correct address; apologies if you get a dup.] I just landed a change (r18813) that may take care of a good number of the spurious rebuilds. Some of the .dll files are built as 'loadable_module' targets, which basically means they don't have any actual code (e.g. only resources) and no symbols to export, so the MS linker doesn't generate a .lib import library for them. However, gyp wasn't setting the necessary property (IgnoreImportLibrary) in the generated .vcproj file to inform Visual Studio that the project wouldn't generate a .lib, and dependent projects shouldn't expect a .lib. So it looks like VS would rebuild the loadable_module target trying to generate a .lib file that would never appear. I'm in the middle of a local rebuild cycle on my system to verify the behavior is actually fixed. (The CL also added 'theme_dll' as dependent target of 'chrome_dll', which would previously generate errors when the lack of the IgnoreImportLibrary property meant that chrome.dll would try to link against the nonexistent default.lib import library for themes.lib) If you still see unnecessary rebuilds after updating to r18813 or later, let me know what targets. There may be other contributing causes. --SK On Thu, Jun 18, 2009 at 4:30 PM, Andrew Scherkus scher...@chromium.orgwrote: Here's a quick example: 1) Delete whole Debug directory 2) gclient runhooks --force 3) Set test_shell as startup project 4) Hit F5 Sample output of things that shouldn't be dependencies (mostly because they're other executables) sandbox (sandbox\sandbox) - Debug Win32 chrome_dll - Debug Win32 net_perftests - Debug Win32 base_unittests - Debug Win32 net_unittests - Debug Win32 v8_shell - Debug Win32 mini_installer - Debug Win32 test_support_unit - Debug Win32 test_support_ui - Debug Win32 codesighs (third_party\codesighs\codesighs) - Debug Win32 automated_ui_tests - Debug Win32 memory_test - Debug Win32 activex_test_control - Debug Win32 On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson bradnel...@google.comwrote: Andrew, can you give an example of something that built that shouldn't have for test_shell? Maybe we have some overspecified dependencies as well. -BradN On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus scher...@chromium.orgwrote: I'll see if I can repro this again before filing a bug, but similar to what Daniel and John reported, when I right click on test_shell and say Build it builds the minimal set required to fully build+link test_shell.exe However when I set test_shell as the start-up project and launch the debugger, Visual Studio warns that every other project in chrome.sln must be built before running (not true!). Is there a difference in build vs. runtime dependencies? Andrew On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote: All-- When you notice missing dependencies, pleased add them to the necessary .gyp file(s)! One of the main reasons we've been trying to land all this stuff is so that tracking down all these pieces isn't single-threaded through one person (or two). If you're not comfortable making the change yourself, then please file a bug so the dependency problems get tracked and fixed in an organized fashion. Re: unnecessary rebuilds: please file bugs so they don't get lost. Please include the target you were building, and the the libs/targets that were rebuilt unnecessarily. You don't have to be exhaustive about the list, it's more important here that at least some information gets collected and doesn't languish on the ML or get dropped on the floor. I'm working on a buildbot script that will test for missing dependencies by building every target from scratch individually, and will then test for unnecessary rebuilds by rebuilding each target after no updates. That's been taking a back seat to just getting the conversion completed, but I've accelerated my work on it as we wind down to the last few targets. --SK On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.orgwrote: Yeah it happened to me before as well, I just figured I'd complain now.. Note another missing dependency is on crash_service.exe , npapi_layout_test_plugin, and npapi_test_plugin btw just to be clear, these are missing dependencies on ui_tests. On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.comwrote: I actually had this problem _before_ this change. Guess I should have brought it up, but I figured it was just something funny on my system. On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.org wrote: +1 this is affecting a lot of people. On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.com wrote: I notice that when I load chrome.sln and do a build, not all the
[chromium-dev] Conventions and patterns for multi-platform development
Our team has had somewhat of an ad-hoc approach to organizing code that's different across platforms. In many cases our approach has been quite good. In others, less so, and there have also been questions about what the preferred method for writing a certain component in a cross-platform way. Last night Ben and I wrote a document that tries to clarify this. It's a combination of what we're doing now that works well, and what we probably should be doing: http://dev.chromium.org/developers/design-documents/conventions-and-patterns-for-multi-platform-development This is linked to from the Engineering design documents page. If you're starting a new component or reorganizing an existing one, try to follow these guidelines. It can't possibly cover every case, so you'll have to use your best judgement. Feedback from people who have done a lot of this stuff would be great. Ideally it would be easy to follow and cover most cases for everybody. Thanks! Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Using custom builds of chromium in a commercial setting
Hi folks, I'm currently investigating the possibility of using SSBs (Site Specific Browsers, another example is mozilla's Prism) to ship alongside a commercial web application, the application does not depend on the SSB in any way just makes it more acceptable to corporations who are opposed to updating to more recent web browsers. I've spent some time perusing the mailing list, and looking at the T's and C's that I can locate on the chromium website ( http://code.google.com/chromium/terms.html ). As far as I can tell the primary license and all 3rd party licenses are 'commecially friendly' and as long as the build of chromium doesn't mention Google or any of the associated trademarks then there should be no problem shipping a customised build of chromium on a cd alongside a commercial product. Can anyone confirm whether or not this is the case ? Many thanks - cj. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] IO Request Handing in Chromium
In http://dev.chromium.org/developers/design-documents/multi-process-resource-loading, all I/O in Render Process (WebKit code) is sent to Browser Process and Browser process is download the resource from the source. But what about Plugins (flash) which runs inside RenderProcess? How can those I/O requests being forward to Browser Process via chromium IPC mechanism? Flash plugins is closed source and it can make more than HTTP request. Flash can make RTMP request for video. How does IO in plugin being handled? Thank you. --~--~-~--~~~---~--~~ 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: does chromium care about appcache manifests?
Developers would surely appreciate some kind of developer mode. Safari makes it nearly impossible to remove an appcache. Refreshing, emptying the cache nor resetting the browser helps in this. MobileSafari behaves about the same -- something like a notice with a force refresh option its developer mode would make debugging a lot easier. I'm not exactly sure what Firefox's behaviour is, but I remember it was somewhat better than Safari. The best way to develop using appcache seems to be by using uncachable references (e.g. timestamped) to every file in the appcache, which is quite tiresome. I'd suggest a 'force reload' option for the first implementation. A UI to show appcaches in some later stage would greatly easy debugging: appcaches are a 'black box' in current implementations. The only way to check that a browser is not reloading is by checking server logs, and even then you still can't be completely sure if it's regular browser caching or an appcache. On Wed, Jun 17, 2009 at 10:11 PM, Michael Nordmanmicha...@chromium.org wrote: Chromium has no behavior whatsoever yet... the feature is utterly unimplemented thus far... but it will have identical behavior to safari, iphone, andriod by virtue of the same code base performing those behaviors... thats the plan at least, and I'm working on the code now. Gears (i'm partly guilty of that) users have similar issues with the gears system. Developing for 'offline' butts heads ( verb noun, not buttheads :O) with standard operating procedures for web development (put new stuff on server, hit reload, repeat as needed). I can think of at least some things that may help? * if the user-agent had a debugging level feature (in some debug/tools menu) to blow away the current appcache. would that help? Or perhaps a UI to show appcaches and a option to 'remove' one? The former could be provided without any spec changes and agreement amoungst browser vendors. We're not far enough along with this feature in chrome to be too concerned with UI yet... but I'll write this down in my design doc. On Wed, Jun 17, 2009 at 5:14 AM, Mark Janssenpraseo...@gmail.com wrote: Hi Michael, It's been some time (I rarely read this address), but why I was asking is because I'm testing a web application for iPhone/Android. Safari does care about appcache manifest, but does so a bit too well: it's nearly impossible get it to reload a new version from the server (thus ignoring the appcache manifest). As you can imagine this is quite cumbersome during development, so I was wondering of Chromium has the same behaviour. Regards, Mark On Mon, Jun 1, 2009 at 11:54 PM, Michael Nordmanmicha...@google.com wrote: Hi, I'm assuming you and praseodym in #chromium IRC are one and the same... if not, sorry for the spam. Yes, we do. At this point, there is no support for the feature in chromium, but we're working towards that. The implementation in webcore has to be refactored so that chromium can use it too... or chromium has to implement this feature outside of webcore... we're pursuing the first option at this time. https://bugs.webkit.org/show_bug.cgi?id=25436 Why do you ask? --~--~-~--~~~---~--~~ 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: What's the TabRestoreUITest bug 1215881?
Pi, If you've tested this on a Vista lemme know.Plz check on WinRC6 coz
there might be
changes in the latest Vista RC; not to mention chrome version changes.
This looks like a k00l bug :P
On Thu, Jun 18, 2009 at 1:53 PM, pi zhu.she...@gmail.com wrote:
Thank Nicolas for your clarify.
Today I find the exception in
AutocompleteEditViewWin::EraseTopOfSelection is caused by the rong
compiler option of 2.0.172.28 official build.
autocomplete_edit_view_win.cc:
HDC BeginPaintIntercept(HWND hWnd, LPPAINTSTRUCT lpPaint) {
BOOL EndPaintIntercept(HWND hWnd, const PAINTSTRUCT* lpPaint) {
These two intercepting win32 API are not explicitly defined as
__stdcall, and are wrongly compiled as __cdecl:
chrome_1c3!`anonymous namespace'::BeginPaintIntercept:
021ea88f
021ea8b5 c3 ret
021ea8c4 c3 ret
chrome_1c3!`anonymous namespace'::EndPaintIntercept:
021ea8c5
021ea8d7 c3 ret
021ea8e6 c3 ret
This is harmless on windows XP, because the corrupted esp is restored
by riched20!RichEditWndProc's leave instruction, and the corrupted esi/
edi/ebx are restored by USER32!InternalCallWinProc.
But it's a disaster on windows 2000, because the corrupted ebx (which
keeps the AutocompleteEditViewWin this point in
AutocompleteEditViewWin::OnPaint) is not restored by USER32!
UserCallWinProc or by USER32!CallWindowProcAorW.
Nicolas Sylvain wrote:
I filed this bug with this comment:--
TabRestoreUITest.RestoreToDifferentWindow fails on win2k debug. I
disabled
it.
This is not reproducible outside the buildbot environment.
The problem seems to be that chrome cannot access a font. I was not able
to
determine what the font was.
---
Later on I fixed it, but forgot to remove the comment.
This bug was only for debug mode, it should not matter for release mode.
Nicolas
--
take the red pill.
Akhil Wali
# http://code.google.com/
# http://aebpy.blogspot.com/
# http://twitter.com/darth10
# http://facebook.com/darth10
--~--~-~--~~~---~--~~
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: Conventions and patterns for multi-platform development
This is awesome! A great read and a good use of examples from our code. Is it worth being more explicit about using MVC to design a new component? Right now it's exemplified in the context of how to allocate memory for the various objects, but a concrete example (the TabStripModel is a good one) might be helpful too. On Fri, Jun 19, 2009 at 12:42 PM, Brett Wilsonbre...@chromium.org wrote: Our team has had somewhat of an ad-hoc approach to organizing code that's different across platforms. In many cases our approach has been quite good. In others, less so, and there have also been questions about what the preferred method for writing a certain component in a cross-platform way. Last night Ben and I wrote a document that tries to clarify this. It's a combination of what we're doing now that works well, and what we probably should be doing: http://dev.chromium.org/developers/design-documents/conventions-and-patterns-for-multi-platform-development This is linked to from the Engineering design documents page. If you're starting a new component or reorganizing an existing one, try to follow these guidelines. It can't possibly cover every case, so you'll have to use your best judgement. Feedback from people who have done a lot of this stuff would be great. Ideally it would be easy to follow and cover most cases for everybody. Thanks! Brett -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Using custom builds of chromium in a commercial setting
I am not a lawyer, but that is the intent. (In some sense Google Chrome is just a commercial consumer of the code base as well. As I understand it, contributors retain copyright on their contributions, so it's not even the case that Google owns all the code that mentions Google in the copyright. See http://code.google.com/legal/individual-cla-v1.0.html ) BTW, Chromium in the App Mode is more or less an SSB. On Thu, Jun 18, 2009 at 3:45 AM, JavaJunkyciar...@gmail.com wrote: Hi folks, I'm currently investigating the possibility of using SSBs (Site Specific Browsers, another example is mozilla's Prism) to ship alongside a commercial web application, the application does not depend on the SSB in any way just makes it more acceptable to corporations who are opposed to updating to more recent web browsers. I've spent some time perusing the mailing list, and looking at the T's and C's that I can locate on the chromium website ( http://code.google.com/chromium/terms.html ). As far as I can tell the primary license and all 3rd party licenses are 'commecially friendly' and as long as the build of chromium doesn't mention Google or any of the associated trademarks then there should be no problem shipping a customised build of chromium on a cd alongside a commercial product. Can anyone confirm whether or not this is the case ? Many thanks - cj. --~--~-~--~~~---~--~~ 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: V8 Generated Constructors
Ah! That did the trick; thanks. On Jun 19, 10:24 am, Dimitri Glazkov dglaz...@google.com wrote: Since Audio object will be instantiated via JS, we need to add extra 2 lines to that huge switch statement in V8Proxy::GetTemplate: case V8ClassIndex::HTMLIMAGEELEMENT: desc-SetCallHandler(USE_CALLBACK(HTMLImageElementConstructor)); break; :DG On Fri, Jun 19, 2009 at 10:05 AM, kylepky...@chromium.org wrote: Ok, I see what you mean, but the macro in v8_proxy.h points to DOM_NODE_TYPES in v8_index.h, which includes VIDEO_HTMLELEMENT_TYPES (V), which conditionally defines V(HTMLAUDIOELEMENT, HTMLAudioElement) if video is enabled (which it is in webkit.gyp). So although that's not exactly the same as image, it looks like that binding does exist. Just because it's another layer away shouldn't mean the audio element isn't a node, correct? I did some more digging, and everything looks ok in HTMLElementFactory.cpp... I have no idea what I'm still missing. On Jun 18, 8:38 pm, Dimitri Glazkov dglaz...@google.com wrote: You're almost there. You also need to make sure to register it in v8_proxy.cpp (look for Image as a pattern to follow). BTW, with gyp, dependencies in bindings are pretty robust. No need to clobber anymore. :DG On Thu, Jun 18, 2009 at 4:05 PM, kylepky...@chromium.org wrote: Ok, so. So far I've created a new file V8HTMLAudioElementConstructor.cpp and modeled it off V8HTMLImageElementConstructor.cpp (changing all images to audios, plus modified V8CustomBinding.h and webkit.gyp. Change is here: http://codereview.chromium.org/132036 But I'm still getting TypeError: Illegal constructor when I try to call the audio constructor. Is there another hook I'm missing? On Jun 16, 11:47 am, Dimitri Glazkov dglaz...@google.com wrote: A good place to start would be to look at existing *Constructor.cpp files in WebCore/bindings/v8 and see how they are hooked in (like Image constructor). Also, you have dimich and levin in close proximity you who have added a V8 constructor or two in the past (I think). ;DG On Mon, Jun 15, 2009 at 5:47 PM, Kyle Preteky...@chromium.org wrote: Hey I'm looking into these layout tests: LayoutTests/media/audio-constructor-src.html LayoutTests/media/audio-constructor.html LayoutTests/media/constructors.html and I need to know how constructors are generated. The failures all appear to be due to the Audio constructor, specifically: TypeError: Illegal constructor Thanks. --~--~-~--~~~---~--~~ 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: changing chrome_exe to chrome, converting chrome.exe to gyp
Just a heads-up, I imagine the various pages such as
http://dev.chromium.org/developers/how-tos/build-instructions-windows
will now need updating, I managed to do my first build of chrome last
night, and my second one this morning, until I read this post I
thought I was going insane g
- cj.
On Jun 18, 8:38 am, Steven Knight s...@chromium.org wrote:
Okay, it looks like this change is sticking, at least until someone
discovers Yet Another Unintended Side Effect. So heed the warnings in the
previous message, quoted below.
Git users on Linux: this requires an update to gyp to work properly, so
make sure you gclient sync after you git pull, or whatever the right
combination of commands is. If you see Python stack traces from gyp
accompanied by complaints about looking up a Dir as a File, make sure the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org wrote:
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert chrome.exe to gyp,
I'm going to (try to) land two changes now that you should be aware of:
1) convert the 'app' target in the chrome.gyp file to being named
'chrome'. 2) actually convert the 'chrome_exe' project to using a
gyp-generated chrome.vcproj file, instead of the checked-in one.
When the first change lands, Mac developers will need to look for the new
'chrome' target instead of 'app', and Linux developers who have been typing
'hammer app' (or 'make app' if you're using the Makefile generator) will
need to type 'hammer chrome' ('make chrome'). The default behaviors of
building everything should be unaffected.
When the second change lands, Visual Studio users will need to use the
'chrome' project, instead of the former 'chrome_exe' project. NOTE:
because the underlying .vcproj file will be completely different, any local
settings you've configured into the old 'chrome_exe' project will NOT be
transferred to the new 'chrome' project. You'll have to make a note of any
custom settings before updating and re-apply them to the new 'chrome'
project.
There's always the chance that one or both of these changes will have to be
reverted if unintended side effects pop up. I'll send out confirming email
with the final state of things.
--SK
--~--~-~--~~~---~--~~
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: IO Request Handing in Chromium
See http://dev.chromium.org/developers/design-documents/plugin-architecturefor some more details. TVL On Fri, Jun 19, 2009 at 1:51 PM, Evan Martin e...@chromium.org wrote: On Thu, Jun 18, 2009 at 12:15 AM, n179911n179...@gmail.com wrote: In http://dev.chromium.org/developers/design-documents/multi-process-resource-loading , all I/O in Render Process (WebKit code) is sent to Browser Process and Browser process is download the resource from the source. But what about Plugins (flash) which runs inside RenderProcess? How can those I/O requests being forward to Browser Process via chromium IPC mechanism? Plugins run in their own separate plugin process. Flash plugins is closed source and it can make more than HTTP request. Flash can make RTMP request for video. How does IO in plugin being handled? Requests made through NPAPI get routed back through the browser's HTTP layer. Other requests go directly to the system, as plugin processes are not sandboxed. (In some sense, getting plugins out of the renderer process is a prerequisite for making renderer processes sandboxable.) --~--~-~--~~~---~--~~ 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: Conventions and patterns for multi-platform development
You may also want to say something about TODO(port) and NOTIMPLEMENTED()s vs. bugs. Just some conventions patterns I could think about. On Fri, Jun 19, 2009 at 18:42, Brett Wilsonbre...@chromium.org wrote: Last night Ben and I wrote a document that tries to clarify this. It's a combination of what we're doing now that works well, and what we probably should be doing: http://dev.chromium.org/developers/design-documents/conventions-and-patterns-for-multi-platform-development This is linked to from the Engineering design documents page. --~--~-~--~~~---~--~~ 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: Conventions and patterns for multi-platform development
This is a great overview! Thanks for writing this up. I wonder if it's worth giving some more guidance about when to use #ifdef vs. say splitting out a couple of methods into a platform-specific file. For example: if you find yourself wrapping the entire body of a function in platform #ifdefs, that may be a sign that it's time to refactor that method into separate per-platform source files; if you find yourself doing so for several methods of a class, it may be time for a helper or delegate class that encapsulates the platform-specific behavior (example: the platform delegate that let us unfork test_shell_main.cc). My concern is that #ifdefs can be great for a spot fix here and there, but if they start growing, they can get unwieldy very quickly and obscure what code is actually getting run on any given platform. --Amanda On Fri, Jun 19, 2009 at 12:42 PM, Brett Wilsonbre...@chromium.org wrote: Our team has had somewhat of an ad-hoc approach to organizing code that's different across platforms. In many cases our approach has been quite good. In others, less so, and there have also been questions about what the preferred method for writing a certain component in a cross-platform way. Last night Ben and I wrote a document that tries to clarify this. It's a combination of what we're doing now that works well, and what we probably should be doing: http://dev.chromium.org/developers/design-documents/conventions-and-patterns-for-multi-platform-development This is linked to from the Engineering design documents page. If you're starting a new component or reorganizing an existing one, try to follow these guidelines. It can't possibly cover every case, so you'll have to use your best judgement. Feedback from people who have done a lot of this stuff would be great. Ideally it would be easy to follow and cover most cases for everybody. Thanks! Brett --~--~-~--~~~---~--~~ 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: Conventions and patterns for multi-platform development
On Fri, Jun 19, 2009 at 9:42 AM, Brett Wilson bre...@chromium.org wrote: Our team has had somewhat of an ad-hoc approach to organizing code that's different across platforms. In many cases our approach has been quite good. In others, less so, and there have also been questions about what the preferred method for writing a certain component in a cross-platform way. Last night Ben and I wrote a document that tries to clarify this. It's a combination of what we're doing now that works well, and what we probably should be doing: http://dev.chromium.org/developers/design-documents/conventions-and-patterns-for-multi-platform-development This is linked to from the Engineering design documents page. If you're starting a new component or reorganizing an existing one, try to follow these guidelines. It can't possibly cover every case, so you'll have to use your best judgement. Feedback from people who have done a lot of this stuff would be great. Ideally it would be easy to follow and cover most cases for everybody. I have a feedback from someone who did not do a lot of this stuff. We should say that we prefer #if defined(OS_WIN) over #ifdef OS_WIN. I always ask myself before doing it, and get confused by seeing the two used in our code base (and even in the same file, like canvas.h) Nicolas Thanks! Brett --~--~-~--~~~---~--~~ 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: Conventions and patterns for multi-platform development
On Fri, Jun 19, 2009 at 11:07 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: We should say that we prefer #if defined(OS_WIN) over #ifdef OS_WIN. In general, you should always prefer #if defined(FOO) over #ifdef FOO, e.g. because you can add || defined(BAR) to the former later. PK --~--~-~--~~~---~--~~ 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: Conventions and patterns for multi-platform development
On Fri, Jun 19, 2009 at 2:11 PM, Peter Kastingpkast...@google.com wrote: On Fri, Jun 19, 2009 at 11:07 AM, Nicolas Sylvain nsylv...@chromium.org wrote: We should say that we prefer #if defined(OS_WIN) over #ifdef OS_WIN. In general, you should always prefer #if defined(FOO) over #ifdef FOO, e.g. because you can add || defined(BAR) to the former later. PK This is already documented in our Chromium coding style guide. Do we need to replicate it? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Conventions and patterns for multi-platform development
On Fri, Jun 19, 2009 at 11:15 AM, Mike Pinkerton pinker...@chromium.orgwrote: This is already documented in our Chromium coding style guide. Do we need to replicate it? No, I was just mentioning that it was a broad principle, not restricted to cross-platform ifdefs. PK --~--~-~--~~~---~--~~ 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: Conventions and patterns for multi-platform development
On Fri, Jun 19, 2009 at 11:15 AM, Mike Pinkerton pinker...@chromium.orgwrote: On Fri, Jun 19, 2009 at 2:11 PM, Peter Kastingpkast...@google.com wrote: On Fri, Jun 19, 2009 at 11:07 AM, Nicolas Sylvain nsylv...@chromium.org wrote: We should say that we prefer #if defined(OS_WIN) over #ifdef OS_WIN. In general, you should always prefer #if defined(FOO) over #ifdef FOO, e.g. because you can add || defined(BAR) to the former later. PK This is already documented in our Chromium coding style guide. Do we need to replicate it? Oops. It was not there when I look at the coding style a long time ago.. Nevermind! Thanks Nicolas -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Tagging WebKit bugs with [Chromium]
I think this is a really good idea, something Maciej has been doing for us in bugs.webkit.org: Anytime you create a WebKit bug that's specific to Chromium port, please add [Chromium] prefix to the bug title. :DG --~--~-~--~~~---~--~~ 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: Tagging WebKit bugs with [Chromium]
On Fri, Jun 19, 2009 at 11:51 AM, Dimitri Glazkov dglaz...@google.comwrote: Anytime you create a WebKit bug that's specific to Chromium port, please add [Chromium] prefix to the bug title. Note: DON'T do this is this is a cross-platform fix that happens to have been found by/affect Chromium. ONLY do this for fixes that are Chromium-specific, or you will delay your patch's review. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Icelandic dictionary for Chrome
I'm hoping to be able to add Icelandic spelling check to Chrome Before I invest a lot of time I have some quick questions/observations: I found an myspell/aspell dictionary for Open Office here: http://wiki.services.openoffice.org/wiki/Dictionaries#Icelandic_.28Iceland.29 and converted it to bdic format using the instructions here: http://dev.chromium.org/developers/how-tos/editing-the-spell-checking-dictionaries. When I replace a supported bdic with this one I can spell check mostly but seen errors such as: Run-Time Check Failure #2 - Stack around the variable 'candidate' was corrupted. (suggestmgr.cxx:680). Any pointers on where to start? I don't know if the dictionary/conversion are at fault or hunspell. Distribution: If I get this to more or less work - how would it possible to distribute it? I want of course the Language Selection UI to have Icelandic and support automatic download of the dictionary. Improvement: If I find issues with either hunspell or the dictionary itself should I work on it in the context of hunspell (which seems to be dormant from their dev mailing list) or what? For the curious more information on Icelandic is here: http://www.iceland.is/history-and-culture/Language/#Grammar Sverrir --~--~-~--~~~---~--~~ 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: Icelandic dictionary for Chrome
On Fri, Jun 19, 2009 at 1:15 PM, Sverrir Á. Bergsver...@chromium.org wrote: I'm hoping to be able to add Icelandic spelling check to Chrome Before I invest a lot of time I have some quick questions/observations: I found an myspell/aspell dictionary for Open Office here: http://wiki.services.openoffice.org/wiki/Dictionaries#Icelandic_.28Iceland.29 and converted it to bdic format using the instructions here: http://dev.chromium.org/developers/how-tos/editing-the-spell-checking-dictionaries. When I replace a supported bdic with this one I can spell check mostly but seen errors such as: Run-Time Check Failure #2 - Stack around the variable 'candidate' was corrupted. (suggestmgr.cxx:680). Any pointers on where to start? I don't know if the dictionary/conversion are at fault or hunspell. Yikes! I have no good input. Most of these bugs have been caused by the code reading the custom format or in its interaction with the rest of Hunspell. Brett --~--~-~--~~~---~--~~ 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: Icelandic dictionary for Chrome
On Fri, Jun 19, 2009 at 1:15 PM, Sverrir Á. Bergsver...@chromium.org wrote: Distribution: If I get this to more or less work - how would it possible to distribute it? I want of course the Language Selection UI to have Icelandic and support automatic download of the dictionary. Sounds like a question best brought up with a lawyer, just to be sure. Improvement: If I find issues with either hunspell or the dictionary itself should I work on it in the context of hunspell (which seems to be dormant from their dev mailing list) or what? It's always polite to send stuff upstream first, but don't let that stop you from making fixes locally if the project has stopped. I'd expect the dictionary owners at least would welcome your changes. --~--~-~--~~~---~--~~ 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: changing chrome_exe to chrome, converting chrome.exe to gyp
Ok so I've tracked down the issue with 'test_shell' not working as a command line target.The issue is that folders in the solution hierarchy apparently cause an ambiguity so devenv doesn't know which one you're referring to, the test_shell folder or the test_shell project. So for instance base_unittests works as a target, but not base. Sigh. Simplest fix I can think of is add a slash to all the folder names. base/ test_shell/ etc. -BradN On Fri, Jun 19, 2009 at 3:10 AM, Dean McNamee de...@chromium.org wrote: This also broke building from the command line. I usually never open Visual Studio as an IDE. I build on the command line with something like: devenv chrome\\chrome.sln /Build release /Project test_shell It looks like project names like test_shell now have complicated names like test_shell (webkit\tools\test_shell\test_shell), and I haven't been able to manage supplying those on the command line. Is there a way we can get back our nice project names test_shell, chrome, etc? On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkusscher...@chromium.org wrote: Here's a quick example: 1) Delete whole Debug directory 2) gclient runhooks --force 3) Set test_shell as startup project 4) Hit F5 Sample output of things that shouldn't be dependencies (mostly because they're other executables) sandbox (sandbox\sandbox) - Debug Win32 chrome_dll - Debug Win32 net_perftests - Debug Win32 base_unittests - Debug Win32 net_unittests - Debug Win32 v8_shell - Debug Win32 mini_installer - Debug Win32 test_support_unit - Debug Win32 test_support_ui - Debug Win32 codesighs (third_party\codesighs\codesighs) - Debug Win32 automated_ui_tests - Debug Win32 memory_test - Debug Win32 activex_test_control - Debug Win32 On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson bradnel...@google.com wrote: Andrew, can you give an example of something that built that shouldn't have for test_shell? Maybe we have some overspecified dependencies as well. -BradN On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus scher...@chromium.org wrote: I'll see if I can repro this again before filing a bug, but similar to what Daniel and John reported, when I right click on test_shell and say Build it builds the minimal set required to fully build+link test_shell.exe However when I set test_shell as the start-up project and launch the debugger, Visual Studio warns that every other project in chrome.sln must be built before running (not true!). Is there a difference in build vs. runtime dependencies? Andrew On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote: All-- When you notice missing dependencies, pleased add them to the necessary .gyp file(s)! One of the main reasons we've been trying to land all this stuff is so that tracking down all these pieces isn't single-threaded through one person (or two). If you're not comfortable making the change yourself, then please file a bug so the dependency problems get tracked and fixed in an organized fashion. Re: unnecessary rebuilds: please file bugs so they don't get lost. Please include the target you were building, and the the libs/targets that were rebuilt unnecessarily. You don't have to be exhaustive about the list, it's more important here that at least some information gets collected and doesn't languish on the ML or get dropped on the floor. I'm working on a buildbot script that will test for missing dependencies by building every target from scratch individually, and will then test for unnecessary rebuilds by rebuilding each target after no updates. That's been taking a back seat to just getting the conversion completed, but I've accelerated my work on it as we wind down to the last few targets. --SK On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.org wrote: Yeah it happened to me before as well, I just figured I'd complain now.. Note another missing dependency is on crash_service.exe , npapi_layout_test_plugin, and npapi_test_plugin btw just to be clear, these are missing dependencies on ui_tests. On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.com wrote: I actually had this problem _before_ this change. Guess I should have brought it up, but I figured it was just something funny on my system. On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.org wrote: +1 this is affecting a lot of people. On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.com wrote: I notice that when I load chrome.sln and do a build, not all the dependencies are built anymore. For instance, theme_dll isn't built (not listed in the proj deps), is this expected? On Jun 18, 12:38 am, Steven
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
Is building the folder expected behaviour, or something we should file with Microsoft? Could just be me but Build project name seems pretty unambiguous that I want to build a project and not a folder... Thanks for looking into the issue! Andrew On Fri, Jun 19, 2009 at 1:53 PM, Bradley Nelson bradnel...@google.comwrote: Ok so I've tracked down the issue with 'test_shell' not working as a command line target.The issue is that folders in the solution hierarchy apparently cause an ambiguity so devenv doesn't know which one you're referring to, the test_shell folder or the test_shell project. So for instance base_unittests works as a target, but not base. Sigh. Simplest fix I can think of is add a slash to all the folder names. base/ test_shell/ etc. -BradN On Fri, Jun 19, 2009 at 3:10 AM, Dean McNamee de...@chromium.org wrote: This also broke building from the command line. I usually never open Visual Studio as an IDE. I build on the command line with something like: devenv chrome\\chrome.sln /Build release /Project test_shell It looks like project names like test_shell now have complicated names like test_shell (webkit\tools\test_shell\test_shell), and I haven't been able to manage supplying those on the command line. Is there a way we can get back our nice project names test_shell, chrome, etc? On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkusscher...@chromium.org wrote: Here's a quick example: 1) Delete whole Debug directory 2) gclient runhooks --force 3) Set test_shell as startup project 4) Hit F5 Sample output of things that shouldn't be dependencies (mostly because they're other executables) sandbox (sandbox\sandbox) - Debug Win32 chrome_dll - Debug Win32 net_perftests - Debug Win32 base_unittests - Debug Win32 net_unittests - Debug Win32 v8_shell - Debug Win32 mini_installer - Debug Win32 test_support_unit - Debug Win32 test_support_ui - Debug Win32 codesighs (third_party\codesighs\codesighs) - Debug Win32 automated_ui_tests - Debug Win32 memory_test - Debug Win32 activex_test_control - Debug Win32 On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson bradnel...@google.com wrote: Andrew, can you give an example of something that built that shouldn't have for test_shell? Maybe we have some overspecified dependencies as well. -BradN On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus scher...@chromium.org wrote: I'll see if I can repro this again before filing a bug, but similar to what Daniel and John reported, when I right click on test_shell and say Build it builds the minimal set required to fully build+link test_shell.exe However when I set test_shell as the start-up project and launch the debugger, Visual Studio warns that every other project in chrome.sln must be built before running (not true!). Is there a difference in build vs. runtime dependencies? Andrew On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote: All-- When you notice missing dependencies, pleased add them to the necessary .gyp file(s)! One of the main reasons we've been trying to land all this stuff is so that tracking down all these pieces isn't single-threaded through one person (or two). If you're not comfortable making the change yourself, then please file a bug so the dependency problems get tracked and fixed in an organized fashion. Re: unnecessary rebuilds: please file bugs so they don't get lost. Please include the target you were building, and the the libs/targets that were rebuilt unnecessarily. You don't have to be exhaustive about the list, it's more important here that at least some information gets collected and doesn't languish on the ML or get dropped on the floor. I'm working on a buildbot script that will test for missing dependencies by building every target from scratch individually, and will then test for unnecessary rebuilds by rebuilding each target after no updates. That's been taking a back seat to just getting the conversion completed, but I've accelerated my work on it as we wind down to the last few targets. --SK On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.org wrote: Yeah it happened to me before as well, I just figured I'd complain now.. Note another missing dependency is on crash_service.exe , npapi_layout_test_plugin, and npapi_test_plugin btw just to be clear, these are missing dependencies on ui_tests. On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.com wrote: I actually had this problem _before_ this change. Guess I should have brought it up, but I figured it was just something funny on my system. On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.org wrote: +1 this
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
I wonder if it would suffice to reorder the project blocks:
Project({2150E333-8FDC-42A3-9474-1A3956D46DE8}) = test_shell,
webkit\tools\test_shell, {6CB66C51-6A84-2C9C-0561-7D059D26064E}
Project({8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}) = test_shell,
..\webkit\tools\test_shell\test_shell.vcproj,
{FA39524D-3067-4141-888D-28A86C66F2B9}
- nick
On Fri, Jun 19, 2009 at 1:53 PM, Bradley Nelson bradnel...@google.comwrote:
Ok so I've tracked down the issue with 'test_shell' not working as a
command line target.The issue is that folders in the solution hierarchy
apparently cause an ambiguity so devenv doesn't know which one you're
referring to, the test_shell folder or the test_shell project.
So for instance base_unittests works as a target, but not base. Sigh.
Simplest fix I can think of is add a slash to all the folder names. base/
test_shell/ etc.
-BradN
On Fri, Jun 19, 2009 at 3:10 AM, Dean McNamee de...@chromium.org wrote:
This also broke building from the command line.
I usually never open Visual Studio as an IDE. I build on the command
line with something like:
devenv chrome\\chrome.sln /Build release /Project test_shell
It looks like project names like test_shell now have complicated names
like test_shell (webkit\tools\test_shell\test_shell), and I haven't
been able to manage supplying those on the command line.
Is there a way we can get back our nice project names test_shell,
chrome, etc?
On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkusscher...@chromium.org
wrote:
Here's a quick example:
1) Delete whole Debug directory
2) gclient runhooks --force
3) Set test_shell as startup project
4) Hit F5
Sample output of things that shouldn't be dependencies (mostly because
they're other executables)
sandbox (sandbox\sandbox) - Debug Win32
chrome_dll - Debug Win32
net_perftests - Debug Win32
base_unittests - Debug Win32
net_unittests - Debug Win32
v8_shell - Debug Win32
mini_installer - Debug Win32
test_support_unit - Debug Win32
test_support_ui - Debug Win32
codesighs (third_party\codesighs\codesighs) - Debug Win32
automated_ui_tests - Debug Win32
memory_test - Debug Win32
activex_test_control - Debug Win32
On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson bradnel...@google.com
wrote:
Andrew, can you give an example of something that built that shouldn't
have for test_shell? Maybe we have some overspecified dependencies as
well.
-BradN
On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus
scher...@chromium.org
wrote:
I'll see if I can repro this again before filing a bug, but similar to
what Daniel and John reported, when I right click on test_shell and
say
Build it builds the minimal set required to fully build+link
test_shell.exe
However when I set test_shell as the start-up project and launch the
debugger, Visual Studio warns that every other project in chrome.sln
must be
built before running (not true!). Is there a difference in build vs.
runtime dependencies?
Andrew
On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org
wrote:
All--
When you notice missing dependencies, pleased add them to the
necessary
.gyp file(s)! One of the main reasons we've been trying to land all
this
stuff is so that tracking down all these pieces isn't single-threaded
through one person (or two). If you're not comfortable making the
change
yourself, then please file a bug so the dependency problems get
tracked and
fixed in an organized fashion.
Re: unnecessary rebuilds: please file bugs so they don't get lost.
Please include the target you were building, and the the
libs/targets that
were rebuilt unnecessarily. You don't have to be exhaustive about
the list,
it's more important here that at least some information gets
collected and
doesn't languish on the ML or get dropped on the floor.
I'm working on a buildbot script that will test for missing
dependencies
by building every target from scratch individually, and will then
test for
unnecessary rebuilds by rebuilding each target after no updates.
That's
been taking a back seat to just getting the conversion completed, but
I've
accelerated my work on it as we wind down to the last few targets.
--SK
On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.org
wrote:
On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek
j...@chromium.org
wrote:
Yeah it happened to me before as well, I just figured I'd complain
now.. Note another missing dependency is on crash_service.exe
, npapi_layout_test_plugin, and npapi_test_plugin
btw just to be clear, these are missing dependencies on ui_tests.
On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.com
wrote:
I actually had this problem _before_ this change. Guess I should
have brought it up, but I figured it was just something funny on
my system.
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
It doesn't seem to, am I missing something?-BradN
On Fri, Jun 19, 2009 at 3:06 PM, Nick Carter n...@chromium.org wrote:
I wonder if it would suffice to reorder the project blocks:
Project({2150E333-8FDC-42A3-9474-1A3956D46DE8}) = test_shell,
webkit\tools\test_shell, {6CB66C51-6A84-2C9C-0561-7D059D26064E}
Project({8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}) = test_shell,
..\webkit\tools\test_shell\test_shell.vcproj,
{FA39524D-3067-4141-888D-28A86C66F2B9}
- nick
On Fri, Jun 19, 2009 at 1:53 PM, Bradley Nelson bradnel...@google.comwrote:
Ok so I've tracked down the issue with 'test_shell' not working as a
command line target.The issue is that folders in the solution hierarchy
apparently cause an ambiguity so devenv doesn't know which one you're
referring to, the test_shell folder or the test_shell project.
So for instance base_unittests works as a target, but not base. Sigh.
Simplest fix I can think of is add a slash to all the folder names. base/
test_shell/ etc.
-BradN
On Fri, Jun 19, 2009 at 3:10 AM, Dean McNamee de...@chromium.org wrote:
This also broke building from the command line.
I usually never open Visual Studio as an IDE. I build on the command
line with something like:
devenv chrome\\chrome.sln /Build release /Project test_shell
It looks like project names like test_shell now have complicated names
like test_shell (webkit\tools\test_shell\test_shell), and I haven't
been able to manage supplying those on the command line.
Is there a way we can get back our nice project names test_shell,
chrome, etc?
On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkusscher...@chromium.org
wrote:
Here's a quick example:
1) Delete whole Debug directory
2) gclient runhooks --force
3) Set test_shell as startup project
4) Hit F5
Sample output of things that shouldn't be dependencies (mostly because
they're other executables)
sandbox (sandbox\sandbox) - Debug Win32
chrome_dll - Debug Win32
net_perftests - Debug Win32
base_unittests - Debug Win32
net_unittests - Debug Win32
v8_shell - Debug Win32
mini_installer - Debug Win32
test_support_unit - Debug Win32
test_support_ui - Debug Win32
codesighs (third_party\codesighs\codesighs) - Debug Win32
automated_ui_tests - Debug Win32
memory_test - Debug Win32
activex_test_control - Debug Win32
On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson bradnel...@google.com
wrote:
Andrew, can you give an example of something that built that shouldn't
have for test_shell? Maybe we have some overspecified dependencies as
well.
-BradN
On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus
scher...@chromium.org
wrote:
I'll see if I can repro this again before filing a bug, but similar
to
what Daniel and John reported, when I right click on test_shell and
say
Build it builds the minimal set required to fully build+link
test_shell.exe
However when I set test_shell as the start-up project and launch the
debugger, Visual Studio warns that every other project in chrome.sln
must be
built before running (not true!). Is there a difference in build vs.
runtime dependencies?
Andrew
On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org
wrote:
All--
When you notice missing dependencies, pleased add them to the
necessary
.gyp file(s)! One of the main reasons we've been trying to land all
this
stuff is so that tracking down all these pieces isn't
single-threaded
through one person (or two). If you're not comfortable making the
change
yourself, then please file a bug so the dependency problems get
tracked and
fixed in an organized fashion.
Re: unnecessary rebuilds: please file bugs so they don't get lost.
Please include the target you were building, and the the
libs/targets that
were rebuilt unnecessarily. You don't have to be exhaustive about
the list,
it's more important here that at least some information gets
collected and
doesn't languish on the ML or get dropped on the floor.
I'm working on a buildbot script that will test for missing
dependencies
by building every target from scratch individually, and will then
test for
unnecessary rebuilds by rebuilding each target after no updates.
That's
been taking a back seat to just getting the conversion completed,
but I've
accelerated my work on it as we wind down to the last few targets.
--SK
On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek
j...@chromium.org
wrote:
On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek
j...@chromium.org
wrote:
Yeah it happened to me before as well, I just figured I'd complain
now.. Note another missing dependency is on crash_service.exe
, npapi_layout_test_plugin, and npapi_test_plugin
btw just to be clear, these are missing dependencies on ui_tests.
On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.com
wrote:
I actually
[chromium-dev] Re: Gmock compilation errors on VS2008SP1
If you didn't see my other mail to chromium-dev, I'll be trying to whack the tr1 dependency next week. That should hopefully fix the issue you were having. Will update this thread again when the patch is committed. -Albert On Mon, Jun 15, 2009 at 9:11 AM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: On Mon, Jun 15, 2009 at 9:03 AM, nakro yoav.zilberb...@gmail.com wrote: Hi albret, projects that fail : gmockj gmockmain here is an example out from gmockmain C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(498) : error C2065: '_Is_swap_move' : undeclared identifier 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple (504) : see reference to class template instantiation 'std::_Move_operation_categorystd::tr1::tuple_Arg0,_Arg1,_Arg2,_Arg3,_Arg4,_Arg5,_Arg6,_Arg7,_Arg8,_Arg9' being compiled 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(499) : error C2226: syntax error : unexpected type 'std::_Move_operation_category_Value::_Move_cat' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2947: expecting '' to terminate template-argument-list, found '' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2976: 'std::_If' : too few template arguments 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include \xutility(1018) : see declaration of 'std::_If' the solution on my machine is this to do HAS_TR1=0 (you have 1 by default) and to change gmock_port.h to include the boost version even on 2008, which initially your code goes to the tuple path That's a good workaround. Switching to the boost implementation would almost certainly work for now. I'll attempt to reproduce and figure out a long term fix (including just whacking the tr1 dependency out of gmock...started a discussion with zhanyong about this last week). If it gets bad enough, we could consider changing over the VS2008 builds to use boost as well, and then disable _HAS_TR1 as you described above, but that'll require a full clobber from everyone due to precompiled header issues. -Albert but i must have something wrong with my machine if i am the only one who is having this --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
