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 <[email protected]> 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 Nelson<[email protected]> > 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 <[email protected]> > 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 Scherkus<[email protected]> > >> 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 < > [email protected]> > >> > 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 > >> >> <[email protected]> > >> >> 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 <[email protected]> > >> >>> 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 < > [email protected]> > >> >>>> wrote: > >> >>>>> > >> >>>>> > >> >>>>> On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek > >> >>>>> <[email protected]> > >> >>>>> 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 <[email protected] > > > >> >>>>>> 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 > >> >>>>>>> <[email protected]> > >> >>>>>>> wrote: > >> >>>>>>>> > >> >>>>>>>> +1 this is affecting a lot of people. > >> >>>>>>>> > >> >>>>>>>> On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx > >> >>>>>>>> <[email protected]> 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 <[email protected]> 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 > >> >>>>>>>>> > <[email protected]> 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
