On Fri, May 8, 2009 at 1:36 PM, John Abd-El-Malek <[email protected]> wrote:
> one small issue I see: the npapi_test_plugin vcproj has a bunch of ".." > folders in the file hierarchy. The attached image explains it better. With gyp the visual studio representation of the files matches the on-disk representation. This was a design choice. Eventually we might want to collapse them, since it's not pretty. Nicolas > > On Fri, May 8, 2009 at 10:05 AM, Darin Fisher <[email protected]> wrote: > >> I forgot to add... Thank You Steven!!!!!!1!1! >> >> >> >> On Fri, May 8, 2009 at 8:51 AM, Darin Fisher <[email protected]> wrote: >> >>> FYI, here's the patch I applied to enable /MP: >>> Index: common.gypi >>> =================================================================== >>> --- common.gypi (revision 15636) >>> +++ common.gypi (working copy) >>> @@ -380,6 +380,7 @@ >>> 'msvs_disabled_warnings': [4503, 4819], >>> 'msvs_settings': { >>> 'VCCLCompilerTool': { >>> + 'AdditionalOptions': '/MP', >>> 'MinimalRebuild': 'false', >>> 'ExceptionHandling': '0', >>> 'BufferSecurityCheck': 'true', >>> >>> >>> >>> On Fri, May 8, 2009 at 3:27 AM, Steven Knight <[email protected]> wrote: >>> >>>> The webkit build on Windows has been converted to using gyp to generate >>>> the Visual Studio .vcproj and .sln files. >>>> You will still see some old .vcproj files checked in to the webkit >>>> directory. Ignore them. They will go away soon, after we've let this soak >>>> just a bit. >>>> >>>> As I type this, the build slaves are all green, modulo "Mac (valgrind)" >>>> which is in the process of running after some of the earlier, unsuccessful >>>> attempts along the way. >>>> >>>> Here are, in no particular order, known gotchas and other things to >>>> watch out for: >>>> >>>> - (Most painful) The bindings generation from the .idl files is no >>>> longer multi-threaded. Beng reported that this increased his build time >>>> from ~5 minutes to ~9 minutes. :-( Coming up with a way to restore >>>> this >>>> multi-threadedness will probably be the highest priority (barring more >>>> severe outright breakages). >>>> >>>> >>>> - There may be missing dependencies among specific targets that >>>> aren't part of the canonical set built by the buildbot slaves. We >>>> already >>>> had the first example, the WebInspector resources not getting installed >>>> for >>>> some targets: http://codereview.chromium.org/115122 >>>> >>>> >>>> - webkit.sln is generated, but chrome.sln is still checked-in. This >>>> means that when you *do* discover a missing dependency that needs to be >>>> restored, you not only have to add it to webkit.gyp, but you also >>>> *must* add >>>> it to chrome.sln in Visual Studio and using sort_sln.py. If you don't, >>>> the >>>> buildbots (which only use chrome.sln) won't know about the dependency. >>>> >>>> >>>> - The generated .vcproj files don't use >>>> build/internal/essentials.vsprops and some of its sibling .vsprops >>>> files. >>>> The new gyp place to look for these sorts of things is >>>> build\common.gypi. >>>> If you need a setting to affect webkit and it"s not there, please add >>>> it, >>>> or ask. >>>> >>>> >>>> - Official packaging hasn't been tested. The generated Debug\ and >>>> Release\ trees have all of the important files in the same locations, >>>> though, which should give us a fighting chance of having things like >>>> packaging and other scripts work reasonably well. Let me know when you >>>> discover something that doesn't, of course. >>>> >>>> >>>> - The sizes of most of the import built-target files (.exe, .dll, >>>> .lib) are nearly identical to the old build, within 1%. I've put up >>>> some >>>> tables here (sorry, Google internal): >>>> >>>> http://www.corp.google.com/~sgk/gyp-Release-sizes.txt >>>> http://www.corp.google.com/~sgk/gyp-Debug-sizes.txt >>>> >>>> >>>> These are just from the builds on my development system, so take them >>>> with a grain of salt. That said, the Release build is very consistent with >>>> the previous sizes, especially the .exe and .dll files. There are some >>>> discrepancies in the Debug build that I haven't accounted for (e.g. 20% >>>> reduction in npapi*dll and test_worker.dll, 17% reduction in wtf.lib). I >>>> suppose that means, despite the green buildbot slaves, that there could be >>>> some different potential behavior lurking. If anyone's bugged by the >>>> discrepancies and would like to help characterize those differences (if >>>> only >>>> for collective peace of mind), let me know. >>>> >>>> I'll check on progress as soon as I'm back among the living. >>>> >>>> --SK >>>> >>>> >>>> >>>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
