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