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 Scherkus<scher...@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> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to