compiling ports with more than one job
freebsd-questions-local at be-well.ilk.org
Wed Feb 28 18:07:27 UTC 2007
Josh Paetzel <josh at tcbug.org> writes:
> On Wednesday 28 February 2007 04:32, Christian Baer wrote:
>> Good morning, 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?
> 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.
More information about the freebsd-questions