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 <da...@chromium.org> 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) <b...@chromium.org>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 <nsylv...@chromium.org>
>> wrote:
>> >
>> >
>> > On Fri, May 8, 2009 at 1:36 PM, John Abd-El-Malek <j...@chromium.org>
>> 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 <da...@chromium.org>
>> wrote:
>> >>>
>> >>> I forgot to add... Thank You Steven!!!!!!1!1!
>> >>>
>> >>>
>> >>> On Fri, May 8, 2009 at 8:51 AM, Darin Fisher <da...@chromium.org>
>> 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 <s...@chromium.org>
>> 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: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to