On Tue, 2010-06-01 at 09:13 +0200, Vaclav Pech wrote:
> Hi Russel,
> 
> it is our build script asking for 8 cores with the "maxParallelForks =
> Runtime.runtime.availableProcessors()" commands. It is the fastest
> setup for me running tests locally, but perhaps there's a better value
> to use in our build script by default.
> 
Apologies to the Gradle team.  Switching discussion to GPars mailing
list.

<<Please make sure that if you reply to this you don't leave the Gradle
mail list entry in place.>>

Sorry, but this choice sucks.  I often have Groovy, Go, Fortress and
Gradle builds on the go simultaneously.  Given 8 cores this works fine
and doesn't kill workstation performance -- until all of a sudden the
GPars build needs 8 cores and now I have a need for 13 cores not to have
UI response killed.  (OK, it is way more complicated than that
but . . . )

 maxParallelForks = Runtime.runtime.availableProcessors()

this is wrong as the project default.  This sort of parallelism has to
be a user request not a project imposition. So if Gradle has no way of
controlling this, we have to write a command line option with an
environment-based or configuration-file-based option as well for the
GPars build

I don't think Gradle has a per-project, per-user config file, but it
does have a per-user one so we can put a variable declaration there.
Accessing the environment is straighforward so we could have a variable
in there.  I can't remember off the top of my head if Gradle allows for
per-project command line options, if not then we have to hack it with a
task.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[email protected]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [email protected]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to