Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Oct 2009 20:07:09 +0000
From:      "b. f." <bf1783@googlemail.com>
To:        Scott Bennett <bennett@cs.niu.edu>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: lang/gcc43 and lang/gcc44 installation procedures broken after  updates
Message-ID:  <d873d5be0910291307r61454678x71da94e58c9d5240@mail.gmail.com>
In-Reply-To: <200910290508.n9T58XqA014030@mp.cs.niu.edu>
References:  <200910290508.n9T58XqA014030@mp.cs.niu.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On 10/29/09, Scott Bennett <bennett@cs.niu.edu> wrote:
>      On Wed, 28 Oct 2009 09:19:08 +0000 "b. f." <bf1783@googlemail.com>
> wrote:
>>On 10/28/09, Scott Bennett <bennett@cs.niu.edu> wrote:
>>>      On Tue, 27 Oct 2009 11:28:51 +0000 "b. f." <bf1783@googlemail.com>
>>> wrote:
>>>>Scott Bennet wrote:

>>MAKE_JOBS_NUMBER?=      `${SYSCTL} -n kern.smp.cpus`
>>_MAKE_JOBS=             -j${MAKE_JOBS_NUMBER}
>
>      I figured it must do something of the sort.  The CPU is an old 3.4 GHz
> P4 Prescott, so it has two logical processors, so MAKE_JOBS_NUMBER gets set
> to 2.  Given the handbook recommendations and my own observations, it seems
> to me that the above method should actually multiply the value of
> kern.smp.cpus by at least 2.5 for best performance.  For CPUs on separate
> cores, 3 is the recommended multiplier, but where HTT logical CPUs are
> involved a multiplier somewhat lower than that is in order.  On the Prescott
> chips, 2.5 seems to work very well, so when I set MAKEFLAGS myself, I set
> it to 5, which is 2.5 * kern.smp.scpus.
>

That seems a bit ambitious.  In any event, It would be better to do
this via the variable MAKE_JOBS_NUMBER, which was created for this
purpose and can be overridden by the user, rather than by using
MAKEFLAGS, which may cause all sorts of problems, among them ignoring
the setting of MAKE_JOBS_UNSAFE.

>>
>>> I guess I will just have to add "-x gcc\*" to the
>>> "portmaster -x perl\*5.8.9\* -a" runs from now on, which is now possible
>>> thanks to Doug Barton's portmaster enhancement that allows multiple "-x"
>>> arguments, and do lang/gcc* updates by the old-fashioned method that
>>> worked
>>> in this case.  I'm not sure what to do if a situation arises like this
>>> for
>>> a port that has many dependencies that would typically be better managed
>>> by
>>> portmaster or portupgrade, however.
>>
>>You don't have to do it on the command line -- you can add the port to
>>HOLD_PKGS in pkgtools.conf with portupgrade, or use a
>
>      I haven't been using portupgrade much lately.  portmaster seems to
> be the recommended tool, and it's certainly a lot faster than portupgrade,

portmaster is more lightweight, but has fewer features.  I roll my own.

>
>
>>/var/db/pkg/*/+IGNOREME as described in portmaster(8).  It's a bit of
>
>      Yes, but that method doesn't work for perl, and IIRC, it doesn't
> work for lang/gcc?? either.  The -x method does, however.
>

It seems to work for me with lang/perl5.10.  What experience have you
had that suggests that it doesn't work with these ports?


b.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d873d5be0910291307r61454678x71da94e58c9d5240>