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