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