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 Scherkus<[email protected]> 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 <[email protected]> > 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 <[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 -~----------~----~----~----~------~----~------~--~---
