I think what you're describing is a list of uses for the tar file. I think they are valid uses, but I would say thata) what you describe as problems with the build system are not "build system" problems, they're more "the tarball doesn't satisfy my usecase" problems. The tarball was not intended to be the build system. b) If you want a specific version of the code, gclient sync --revision src@ ####
Really, the most basic goal of the tar file was that just before launch day, we were launching a huge open source project and I was looking at projected queries per second (QPS) to the SVN server and freaking out. As such, we put up the tarball to reduce the load. (Even with that, I think the SVN server prettymuch keeled over on launch day). We actually didn't even start doing updates to the tarball until recently (for quite a while it was still the initial version of the source code). What you're describing are other valid use cases, but given everything else we're trying to work on, and given that they can be satisfied by other (relatively simple) methods, I don't (personally) think it's worth trying to solve the issues you point out with the tarball. Certainly that wasn't the original intent for providing the tarball. my $0.02 On Wed, Feb 4, 2009 at 10:31 AM, noemata <[email protected]> wrote: > > I had also assumed that the tar ball and SVN repository were > complete. Though I appreciate the arguments associated with the > manner in which the build process is implemented, ultimately it ends > up being self limiting. At present, there is no easy way to have > historical snapshots of working releases. This is a fairly common > practice that simplifies certain forms of regression testing. > > In our internal effort, I am the one dolling out a functional build of > Chromium by packaging a working archive file for others. The gclient > idea works, but it is fragile. It's much simpler to provide a fully > vetted build environment rather than rely on a tool that has to push > and pull it into place on a developer's system. > > Needing to accommodate different OS build targets is precisely why you > want to have OS specific tar archives. It's trivial to do. The only > reason I would choose not to do so is to obfuscate the build process, > thus keeping a certain class of software developer away from working > with Chromium. > > Running the test suite is even more fragile than building Chromium. > On my setup, most tests fail because it seems like the test > environment isn't configured correctly. I suspect this isn't > intended. Yet another self limiting characteristic of the present > build system. > > Surely, it's not that hard to have three sets of archives that provide > a complete snapshot of a working build environment. Internal to > Google, you must gen these anyways, so what's the issue? All such > archives should deliver a built version of Chromium to the recipient > so they can fire up the tests. I see this as the most basic goal of > the tar archive. Second to that is actually building it. > > On Feb 4, 3:13 am, Pam Greene <[email protected]> wrote: > > We could make fully self-sufficient tarballs, but then we'd need three > > separate ones, since the three platforms have different dependencies. > (Or > > we'd need to stick Mac and Linux developers with downloading a bigger > > tarball than they need.) I think it's fair to require a sync after > > downloading the tarball, since you'll need to have the tools working at > some > > point. If you don't ever want to update your source code, you can use the > > "continuous" builds. > > > > (For the moment, since the tarballs are generated arbitrarily at 2 AM, > > syncing to a working build is a good idea anyway. But I plan to change > it > > to package up a known-green revision.) > > > > - Pam > > > > On Tue, Feb 3, 2009 at 9:57 PM, Nicolas Sylvain <[email protected] > >wrote: > > > > > > > > > > > > > On Tue, Feb 3, 2009 at 9:55 PM, Brett Wilson <[email protected]> > wrote: > > > > >> On Tue, Feb 3, 2009 at 9:05 PM, <[email protected]> wrote: > > >> > What evan means is that after downloading the tar ball, you need to > run > > >> > gclient sync to get all the platform specific dependencies. > > > > >> > We recently started generating the source tar ball on a regular > basis > > >> and > > >> > it doesn't include all the Windows and Mac dependencies from the > > >> > src/third_party directory. Running gclient sync will download these > > >> > platform specific dependencies for you. > > > > >> In that case, the build instructions are out of date. I updated the > > >> getting-the-code page to reflect that this is now required. > > > > > If this is now required, we screwed up somewhere. The goal of the > tarball > > > is mainly to give an easy way for people to download and build > chromium. If > > > they need to call gclient sync, it defeats the purpose. > > > > > Are you sure we really need that? > > > > > Nicolas > > > > >> Brett- Hide quoted text - > > > > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
