Re: Testing parallel builds
On Monday 08 October 2007 08:30:53 am Pierre Habouzit wrote:
> On Mon, Oct 08, 2007 at 12:07:12PM +0000, Daniel Schepler wrote:
> > On Monday 08 October 2007 07:49:09 am Pierre Habouzit wrote:
> > > On Mon, Oct 08, 2007 at 10:53:05AM +0000, Daniel Schepler wrote:
> > > > Inspired by today's new upload of dpkg, I'm going to try doing a
> > > > rebuild of the archive using "dpkg-buildpackage -j3" and submit bugs
> > > > as I find them. The bugs will be wishlist for now, and I'll assign
> > > > usertag firstname.lastname@example.org:ftbfs-parallel to those bug reports
> > > > for those interested in tracking the issue.
> > >
> > > Err please just don't. Many upstreams won't build properly with
> > > parallel builds because their makefile just don't support it. Most
> > > importantly, I believe that only the biggest packages benefit from a
> > > parallel build, hence it should be an opt-in option that packagers may
> > > use if their package support it, and if they believe it matters
> > > (packages where build time is under the few minutes won't benefit from
> > > it a lot e.g., as it's probable that most of the time is lost in the
> > > configure and Debianization stages).
> > Then isn't that something that should be fixed? With dual-core
> > processors becoming more and more common, I would expect some users
> > (myself included) to be in the habit of typing `make -j2' or
> > `dpkg-buildpackage -j3' to take advantage, and then get annoyed if it
> > doesn't work.
> Well, try to fix the ocaml build-system to work in parallel, if you
> are able to do it, I'll gladly fix the rest of Debian makefiles :P
OK, I'll look into that when I get some free time.
> > Especially when the easy work-around, if you don't want to bother adding
> > the proper dependencies to the make targets, is just to add
> > ".NOPARALLEL:" somewhere in the Makefile.
> This is a GNU extension.
So is -j, I think. It shouldn't break anything if the system make doesn't
> > Anyway, I'm aware a lot of packages will probably break at the moment,
> > which is why I'm using wishlist.
> I still believe that you should not file such bugs, I still fail to
> see how it improves debian, as if we really need to build more packages
> at the same time, we could run many sbuild instances on the same
What about the case of someone wanting to debug a large package that
hasn't "opted in" under your model? Then either I have to try calling
dpkg-buildpackage with -j and run the risk that it might silently break
somehow, or else put up with a longer build time.
Also, adding the -j flag to dpkg-buildpackage IMHO creates the expectation
that it should work on most packages. Are you going to file a bug on
dpkg-dev asking for that to be removed?