On Wed, Jun 28, 2006 at 03:22:35PM +0200, Ingo Juergensmann wrote:
> On Wed, Jun 28, 2006 at 01:37:37PM +0200, Adam Borowski wrote:
> > The benefits on UP are small (~10%), but except for huge working
> > sets, non-negative.  And the maintainer knows if the package handles
> > huge chunks at once or not.
> Right. The maintainer should know it. But when the benefits are so small,
> one can argue if it's worth the work to change the build system? ;)
> Therefore I think it's best to first go with opt-in before make opt-out the
> default, let's say when etch+2 is out.

What I mean is opt-in for the maintainer, opt-out for the builder.
And the benefits are small only on UP.
   
> > > I would like to see a method to allow usage of other compile accelerators 
> > > as
> > > well (distcc (for using crosscc, but testing locally), ccache, etc). 
> > In theory, you would set CC, but not everything obeys it.  I
> > personally tend to mess with what "gcc" points to.  Usually with more
> > than one levels of indirection, too -- colorgcc is a nice thing for
> > when the output goes to a terminal.
> Of course, but my point is: when we make a decision now about -j flag, we
> can have some thougts about such accelerators as well and implement both in
> one go instead of having two separate changes to the build system. 

"changes to the build system"?  Where?

Note that in my proposal there are exactly no changes to the global
build system, except for a flag that can be set to force a package to
go down to -j 1.  No legislation needed.

And with the guessing code in my debian/rules (package kbtin on
m.d.n, as per the sibling branch of the thread), even that flag is
not needed.  On a small box, the package will go down to -j 1 without
any admin intervention.

I'm not talking about etch+2, I'm talking about something that can go
into the archive right now.  Just opt-in by including in debian/rules
the code of which v0.1 I uploaded to mentors.

Whee?
-- 
1KB             // Microsoft corollary to Hanlon's razor:
                //      Never attribute to stupidity what can be
                //      adequately explained by malice.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to