[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
There are a certainly performance bugaboos at the moment (I've been keeping your email in my inbox as a reminder :-) )One thing just jumped out at me though, the environment variable we're checking for cores on windows in NUMBER_OF_PROCESSORS, not NUM_CPUS (at least for the makefile step in webcore). -BradN On Fri, Jul 3, 2009 at 6:38 AM, Dean McNamee de...@chromium.org wrote: Hey Bradley, Thanks, I can build again from the command line. My CPU utilization is still annoying low. I made sure and NUM_CPUS is 4. Compare this to the Linux make build, which keeps my 4 cores at 100% cpu all the way through. Thanks -- dean On Sun, Jun 28, 2009 at 2:06 AM, Bradley Nelsonbradnel...@google.com wrote: Hi Dean, So I've dropped in a change that switches directories to have name like: (base) (test_shell) This will allow you to run things at the command line again. I don't find this choice particularly ascetic myself. But the options where limited, because the following characters cannot appear in solution folder names: / ? : \ *| # % Let me know if you run into any more problems with this. Also definitely let me know if someone thinks of something less ugly. -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:
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
Hey Bradley, Thanks, I can build again from the command line. My CPU utilization is still annoying low. I made sure and NUM_CPUS is 4. Compare this to the Linux make build, which keeps my 4 cores at 100% cpu all the way through. Thanks -- dean On Sun, Jun 28, 2009 at 2:06 AM, Bradley Nelsonbradnel...@google.com wrote: Hi Dean, So I've dropped in a change that switches directories to have name like: (base) (test_shell) This will allow you to run things at the command line again. I don't find this choice particularly ascetic myself. But the options where limited, because the following characters cannot appear in solution folder names: / ? : \ *| # % Let me know if you run into any more problems with this. Also definitely let me know if someone thinks of something less ugly. -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
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
Hi Dean, So I've dropped in a change that switches directories to have name like: (base) (test_shell) This will allow you to run things at the command line again. I don't find this choice particularly ascetic myself. But the options where limited, because the following characters cannot appear in solution folder names: / ? : \ *| # % Let me know if you run into any more problems with this. Also definitely let me know if someone thinks of something less ugly. -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
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
FYI, I'm pretty sure you'll receive a WontFix, especially that VS2010 is using MSBuild instead of vcbuild. M-A On Fri, Jun 19, 2009 at 6:01 PM, Andrew Scherkusscher...@chromium.org wrote: 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.com wrote: 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
[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] 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] 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: 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: changing chrome_exe to chrome, converting chrome.exe to gyp
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: changing chrome_exe to chrome, converting chrome.exe to gyp
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 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: changing chrome_exe to chrome, converting chrome.exe to gyp
I'm also noticing that every time I do a build/debug, it's rebuilding
a LOT of the libraries even though nothing has changed.
On Jun 18, 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 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: changing chrome_exe to chrome, converting chrome.exe to gyp
+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
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: changing chrome_exe to chrome, converting chrome.exe to gyp
Another missing dependency, in the runtime sense, is unit_tests
on test_chrome_plugin. Right now if you just compile that project from a
clean build, it'll crash.
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.comwrote:
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
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: changing chrome_exe to chrome, converting chrome.exe to gyp
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.comwrote:
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
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: changing chrome_exe to chrome, converting chrome.exe to gyp
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
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.orgwrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.comwrote:
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
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: changing chrome_exe to chrome, converting chrome.exe to gyp
2009/6/18 Jeremy Orlow jor...@google.com
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.
I, too, had this problem (theme.dll not being built) _before_ this change
and I didn't bring it up for the same reason as Jeremy ;-)
Also, when I use increbuild (this is again before the change. and I haven't
updated my tree after sgk's checkin) to do a clobber-build, header files
supposed to be generated out of grd are not generated and I have to build
related projects manually.
Jungshik
On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.orgwrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.comwrote:
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
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: changing chrome_exe to chrome, converting chrome.exe to gyp
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.orgwrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.comwrote:
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
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: changing chrome_exe to chrome, converting chrome.exe to gyp
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.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.orgwrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx
daniel.c...@gmail.comwrote:
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
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
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
I'll add the dependencies I was complaining about :)
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.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.orgwrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx
daniel.c...@gmail.comwrote:
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
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: changing chrome_exe to chrome, converting chrome.exe to gyp
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.orgwrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx
daniel.c...@gmail.comwrote:
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
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
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
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. There was a thread on chromium-dev about it a few weeks ago, which is why you probably didn't hear more people complain. --~--~-~--~~~---~--~~ 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
I'll add the dependencies I was complaining about :)
John just came by with some questions, so in the interests of sharing
information more widely, here's the executive summary for adding
dependencies you notice missing:
- There's no distinction in gyp between build-time and run-time
dependencies.
- If a target needs something built by another target at build time *or*
run-time, it needs to be added to the (a) 'dependencies' section of the
relevant target's dictionary.
- You refer to another target as a dependency just by name if it's in the
same .gyp file:
'dependencies': [
'other_target',
],
Or by filename.gyp:target if it's in another .gyp file:
'dependencies': [
'../other/other.gyp:other_target',
],
- Other .gyp file names are always specified relative to the .gyp file
you're in.
- If the dependency is only applicable to a single platform (Windows) it
needs to go down in a conditions section, usually towards the bottom of the
target's dictionary:
'conditions': [
['OS==win', {
'dependencies': [
'../other/other.gyp:other_target',
],
}],
],
- Yes, navigating the nested dictionaries and lists can drive you a
little bonkers.
Don't hesitate to ask for help or ask questions.
--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: changing chrome_exe to chrome, converting chrome.exe to gyp
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.orgwrote: +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 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
