I have got the answer from IRC :) All good, thanks! [01:38:32] <+maruel> m0: yeah we'll look at fixing that next week [01:39:00] <+maruel> all the idl parsing is serialized now [01:43:59] <+beng_home> m0: the webkit gyp build is spinning up the cygwin init script for every autogen file [01:44:04] <+beng_home> m0: sgk has a fix for that [01:44:14] <+beng_home> it's also not generating files in parallel [01:44:20] <+beng_home> it's being worked on
-- Mohamed Mansour On Sat, May 9, 2009 at 1:42 AM, Mohamed Mansour <[email protected]>wrote: > Very nice job Steven! > I have a question (as always :)) Now the build takes tremendously a lot > more time. It has been going on for over an hour (used build it from scratch > in around 20 minutes). I have noticed in VS it is spitting too many WebKit > warnings, (maybe that is why it is slowing it down), there is around 30000+ > warnings (32252 and still counting) If there is a way to minimze those > warnings being printed to the screen, maybe that will help my build go > quicker. > > Thanks! > > > > -- Mohamed Mansour > > > > On Fri, May 8, 2009 at 5:42 PM, Darin Fisher <[email protected]> wrote: > >> Eventually (soon, i hope), the webkit build files will move into >> svn.webkit.org, so this issue will go away. >> -Darin >> >> >> On Fri, May 8, 2009 at 2:29 PM, Ben Goodger (Google) >> <[email protected]>wrote: >> >>> +1 to cloning disk layout for chrome source - it makes it much easier >>> to find things! >>> >>> for third_party stuff where the build config lives in a different dir >>> structure to the source, it might be possible to add a "dir base" or >>> something to the target info which specifies the dirs to strip off the >>> front perhaps? >>> >>> -Ben >>> >>> On Fri, May 8, 2009 at 2:14 PM, Nicolas Sylvain <[email protected]> >>> wrote: >>> > >>> > >>> > 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 -~----------~----~----~----~------~----~------~--~---
