Yes... that's what I'd imagine us doing... just because we suck in projects A, B, C doesn't mean they need to conform to our "include starts at the root" convention - as far as they're concerned the root is src/ in their repo.
-Ben On Wed, May 13, 2009 at 12:39 PM, Darin Fisher <[email protected]> wrote: > That is what I meant by pain.... > It only applies to "third party" code that conforms to the google style > guide, which says that all include paths must be relative to the root. Come > to think of it, I think this could cause problems for such projects, since > I'm sure the V8 developers don't think of V8 as a third party piece of code, > and in their world, V8 is not checked out into a directory named > third_party. We'd probably end up having to add "src/third_party" to the > include path or something like that. > -Darin > > On Wed, May 13, 2009 at 12:35 PM, Ben Goodger (Google) <[email protected]> > wrote: >> >> Really? I don't think we include anything in third_party using >> third_party in the include path - or is this not what you mean by >> "pain"? >> >> -Ben >> >> On Wed, May 13, 2009 at 12:32 PM, Darin Fisher <[email protected]> wrote: >> > I think that's a good point, and it would make for a much easier to >> > understand and enforce policy. It means some potential pain if we ever >> > wish >> > to fork a top-level directory off into a separate opensource project. >> > -Darin >> > >> > On Wed, May 13, 2009 at 10:56 AM, Ben Goodger (Google) >> > <[email protected]> >> > wrote: >> >> >> >> I do think this distinction is fairly arbitrary in the world of open >> >> source projects. It is not hard to imagine a time when some of these >> >> dependencies may have more non-Google contributors than Googlers. It >> >> is also possible that licensing may change over time. >> >> >> >> In addition, it makes it harder to distinguish what top level dirs we >> >> have that aren't provided by deps. >> >> >> >> My personal preference is that everything that isn't hosted in our >> >> repo goes into third_party regardless of whether its license agrees >> >> with ours at this moment. >> >> >> >> -Ben >> >> >> >> On Tue, May 12, 2009 at 3:55 PM, Darin Fisher <[email protected]> >> >> wrote: >> >> > On Tue, May 12, 2009 at 3:06 PM, Brett Wilson <[email protected]> >> >> > wrote: >> >> >> >> >> >> On Tue, May 12, 2009 at 2:48 PM, Nicolas Sylvain >> >> >> <[email protected]> >> >> >> wrote: >> >> >> > On Tue, May 12, 2009 at 2:22 PM, Stephen White >> >> >> > <[email protected]> >> >> >> > wrote: >> >> >> >> >> >> >> >> I'm in the process of updating chromium to use tip-of-tree skia, >> >> >> >> and >> >> >> >> in >> >> >> >> the same CL, moving skia to a third_party directory, >> >> >> >> retrieved via DEPS. What this means for you: >> >> >> > >> >> >> > Hi, >> >> >> > Why do you want to move it to third party? >> >> >> > The other projects developed at google that we fetch through DEPS >> >> >> > like >> >> >> > googleurl, breakpad, gtests and courgette are all living in src, >> >> >> > not >> >> >> > third_party.. >> >> >> > Nicolas >> >> >> >> >> >> If our repo is not the canonical representation, they should all be >> >> >> in >> >> >> thierd party. So I think that all your examples are in the wrong >> >> >> place. >> >> >> >> >> >> Brett >> >> > >> >> > >> >> > src/courgette is the canonical representation. we placed googleurl, >> >> > breakpad, and v8 in src and not third_party because they are >> >> > developed >> >> > by >> >> > our team, so we do not have licensing / copyright concerns. >> >> > the rule we have been following is to put items in third_party that >> >> > do >> >> > not >> >> > conform to our licensing or that are developed by another group. i >> >> > think by >> >> > this measure it is correct for googleurl, breakpad, and v8 to live in >> >> > src. >> >> > same goes for gtest. skia seems like a borderline case to me. >> >> > the point of third_party is to make ease the job of a licensing >> >> > lawyer >> >> > who >> >> > has to figure out what they need to worry about. >> >> > -darin >> >> > >> >> > >> >> > >> > >> > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
