Re: compiling ports with more than one job

Josh Paetzel <josh@xxxxxxxxx> writes:

On Wednesday 28 February 2007 04:32, Christian Baer wrote:
Good morning[1], folks!

I am currently setting up a Sun U60 with FreeBSD. A few amount of
apps will be installed on it, when I'm through with it. And that is
where it gets a little frustrating.

The packages for SPARC64 aren't really up to date. That is why
using them isn't really an option. Besides, some programs actually
get a real boost if they are compiled with an -mcpu flag, which
probably isn't set when the packages are compiled. So, I'm down to
installing them over the ports collection.

That isn't bad in itself. But even a U60 isn't really a fast
machine and if you compile bigger collections (like x.org, kde,
firefox etc.) you can watch yourself aging while the machine is at
it. It would be a great help if I could really use both CPUs in
this machine. But somehow that doesn't work. I have observed two
things so far (in general):

Some ports (like mc) have a menu for choosing the compile options.
If I try to make one of those with more than one job (make -j 2) I
can't hit any of the boxes on the list of options or even hit the
"ok" button. It would seem that make went on to the next job
without actually waiting for the input.

The same background but with a slightly different effect is also
true for ports without a menu. I couldn't make xorg with more than
one job because make just ran on without waiting for the required
things to be there and stopped with a "no such file or directory".
That is quite a drag as on UltraSPARC II CPUs compiling isn't much
fun even if you use all the CPU-power there is.

Normally you'd think that a meta-port like xorg just hast to be
compiled step by step. However, a far more complex system (make -j
4 buildworld) works just fine.

Am I too thick to get the point here or is it really true that the
ports in general will only compile correctly one job at a time?

Regards
Chris

The issues with the config screen sounds like a bug, but one that is
unlikely to get fixed any time soon. You can avoid it by doing a
make config-recursive before building the port, but you're still
going to run in to the problem that ports are not guarranteed to
by -jX safe, some will work, some won't, and there's no way of
knowing without trying it. In general you can save yourself a lot of
headaches by not trying in the first place.

Exactly right. However, you can get some parallel building by doing
more than one single-threaded build at the same time. This leads to
some danger of corrupting the database, though, so it's not for the
squeamish. I know that portupgrade uses locking to control those
problems, and I suspect some of the other port-management ports
probably have similar capabilities.
_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"

Quantcast