On 04/01/2012 03:45 AM, Auguste Pop wrote: > i am not sure why are you trying to do it in PKGBUILD. if you have > several machines that you want to have different settings, why not set > /etc/makepkg.conf or $HOME/.makepkg.conf separately? > > anyway, i think the following command can easily get the information you need: > grep -c processor /proc/cpuinfo Thanks All, Auguste, I was really just brainstorming and I ran out of answers, so I asked on the list. What started this was just the question: "What can I do (if anything) to optimize the --jobs setting for trinity builds for anyone who decided to try building it?" I didn't even know how much difference the make --jobs=X could make on build time. It turns out to make a LOT of difference with quad core processors. A quick example is Amarok. With --jobs=0 on a phenom 9850 w/8G, the build takes 10 minutes. With --jobs=4, it builds in just over 2 minutes. That is a factor of five on rebuilds - literally cutting hours off the build time of trinity. I always wondered why anyone would care how many cores a processor has, because for desktop use -- I can't tell much difference at all on how a desktop behaves. However -- the usefulness of the additional cores was instantly clear when building large packages. So I was wanting to tweak the: make || return 1 line in the pkgbuild files to optimize build times for whoever was building (even if they hadn't made friends with makepkg.conf yet) Then thinking further about it, the Arch setup using makepkg.conf just made that much more sense. If a user is building that large of projects, then they should be at a point to learn to optimize makepkg themselves. That and the additional build instability (small, but it makes a difference with some code) of parallel builds by forcing --jobs=X in the pkgbuild, looked like a bad idea all the way around. However, I do thank you for the grep -c processor /proc/cpuinfo tip. -- David C. Rankin, J.D.,P.E.
