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