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