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.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 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
-~----------~----~----~----~------~----~------~--~---
