compiling ports with more than one job

[Lowell Gilbert]

Josh Paetzel <josh at tcbug.org> 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.