That's basically what we had before.
You can add entries to a DEPS file that have the value From("foo"), and that
causes the value of the entry to be taken from the path foo/DEPS, where foo
is a directory at the same level as the directory containing the DEPS file
that mentioned From("foo"). Originally, chrome's DEPS file lived in
chrome/DEPS instead of src/, and the submodules were the ones that were
siblings to the chrome directory.
There's a lot of shared dependencies. I'm not sure that for trunk
development, it makes sense to require a WebKit roll to update DEPS for all
of those shared dependencies. I'm concerned that will slow us down.
Can we try having separate sets of dependencies for now? I think the point
of the WebKit standalone build is to help vet changes to WebCore. It is
less about vetting changes to the modules. The canary bot can cover those.
We could write a tool to sync deps, which we run periodically. I think the
Chromium repository should probably hold the truth.
-Darin
On Tue, Sep 29, 2009 at 4:46 PM, David Levin <[email protected]> wrote:
> What about the override approach that I mentioned?
> Have the dependency listed in webkit alone. If you need to roll the deps
> before rolling webkit, add a line in the chromium deps that overrides the
> one from webkit.
>
>
> On Tue, Sep 29, 2009 at 3:00 PM, Darin Fisher <[email protected]> wrote:
>
>> On Tue, Sep 29, 2009 at 1:12 PM, David Levin <[email protected]> wrote:
>>
>>>
>>>
>>> > Q: When I change src/DEPS, do I also have to change upstream
>>>> > third_party/WebKit/WebKit/chromium/DEPS?
>>>> > A: It depends why you update src/DEPS. Theoretically, you should only
>>>> update
>>>> > the upstream DEPS if the fix to the dependency actually changes the
>>>> way
>>>> > webkit interacts with it, or fixes a bug in the webkit layout tests.
>>>> > However, if the change is only relevant to chromium, than webkit's
>>>> DEPS need
>>>> > not be updated. If that change breaks webkit, we will surely find it
>>>> when we
>>>> > build chromium.
>>>>
>>>
>>> This seems like a mistake having out of sync rev may cause all sorts of
>>> issues. Here's a simple one suppose there is a rev that fixes some issue and
>>> adds an assert and it is only done in chromium.
>>>
>>> Now code is changed in webkit which would trigger this assert. This
>>> increases the pain for rolls and seems like a mistake.
>>>
>>>
>> Ask anyone who was around when we had transitive deps. It royally sucked.
>> I really do not want to go there again ;-)
>>
>> Once we finish the WebKit API, we'll be able to make Chromium tip-of-tree
>> use a snapshot of WebKit. However, we might need to rev Skia independently
>> to pick up features for the Chrome UI. We shouldn't have to branch WebKit
>> just to update Skia. Same goes for the majority of the shared dependencies.
>>
>> I think it is better if we have two separate configurations. Testing
>> WebKit in isolation just depends on some reasonable set of dependencies.
>> Then, we'll also test Chromium+WebKit(head) using the canary bots. This
>> will test with dependencies matching those used by Chromium+WebKit(stable).
>> So, I think we'll get the coverage we need.
>>
>> Another choice is to have a shared master location for dependencies.
>> However, both svn.webkit.org and svn.chromium.org would need to hardcode
>> the revision of that master location, so you are back to having to rev a
>> number in two locations. We don't want to have either repository pointing
>> to the head of the master location since that would make it difficult to cut
>> branches or refer to a particular revision of the repository.
>>
>> -Darin
>>
>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
