On Sun, Jun 25, 2006 at 06:51:31PM +0200, Petter Reinholdtsen wrote:
> [Lars Wirzenius]
> > As far as I can see, using make's -j option is only useful if you
> > have multiple processors. Packages should not make such assumptions
> > of the build environment.
> Actually, I've seem speedup with -j2 on a single CPU machine. I
> suspect one process is compiling while the other fetches the source
> from disk. :)
Yes, I've seen similar behaviour as well, not only with make/compiler.
Overloading can speed up things for rendering processes as well, depending
on the arch. But that's not the point here.
Although gem was using 4 parallel makes, the buildd performed quite well,
but this was just luck. If the source file would've been bigger in size, it
would have been bad for the buildd. However, not all buildds have 128M or
more memory. For example the armeb buildds only have 32M and Joey said
something that the (or some) arm buildds are just having 64M w/o swap.
So, finding a solution for this "problem" would be nice. When you have more
core/CPUs you may want to make use of these, but it should be configurable
by the buildd admin, if it's ok for a package to use multiple instances of
the compiler. So, some sort of an environmental variable needs to be set, I
think.
The package could then check for this variable and when it is known to build
without any problems using -jX, it can go right away doing so. Otherwise it
should use -j1 (or no -j option at all).
When a policy change is needed, I think it would be worthwhile to think of
allowing crosscompiler builds as well. When there would be a way to use
distcc on slower archs to crosscompile large packages, it would make many
people happy, I think. ;)
But of course the very first question is: is it wanted that there's
something like that in the future or not?
If yes, then let a group of porters, policy people and such decide how this
can be achieved in the best way and let them make a proposal after some
time.
Porters are needed because they will have to deal with those issues when a
build fails because of this. Policy people, because they need to write it
down. DAK people, because they need to implement the needed changes, etc...
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: [EMAIL PROTECTED]
gpg pubkey: http://www.juergensmann.de/ij/public_key.asc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
