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