[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: new build system

From: Sadinoff, Daniel <daniel.sadinoff_at_gs.com>
Date: 2001-05-30 21:37:59 CEST

Actually, current versions of GNU-make are very recursion-friendly:

from the NEWS for version 3.78 of GNU-make:

* A "job server" feature, suggested by Howard Chu <hyc@highlandsun.com>.

  On systems that support POSIX pipe(2) semantics, GNU make can now pass
  -jN options to submakes rather than forcing them all to use -j1. The
  top make and all its sub-make processes use a pipe to communicate with
  each other to ensure that no more than N jobs are started across all
  makes. To get the old behavior of -j back, you can configure make
  with the --disable-job-server option.

-----Original Message-----
From: Greg Stein [mailto:gstein@lyra.org]
Sent: Sunday, May 27, 2001 3:06 AM
To: Garance A Drosihn
Cc: dev@subversion.tigris.org
Subject: Re: new build system

On Sun, May 27, 2001 at 12:29:36AM -0400, Garance A Drosihn wrote:
>...
> >Then there is that whole recursion thing I mentioned. We get
> >speed and clarity with the new system. Removing automake and
> >its bazillion substitutions has also dramatically sped up
> >autogen.sh and the last step of ./configure.
>
> Speeding up the build process also sounds like a win. As long
> as it all works right, this seems like a worthwhile alternative
> to try out. If it works, then faster builds are always nice
> to have!

If it didn't work, I wouldn't have checked it in :-)

> (any idea how well this works with 'make -j'?)

Actually, make -j should work much better with the single makefile. It can
parallelize the entire build, not just the bits within a single directory.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:31 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.