On 18/01/2011, at 12:51 AM, Etienne Studer wrote: > +1 to keep --no-opt > > Sometimes it is useful to run a task even if input/output have not changed. > For example, I often do a gradle -d <task> --no-opt to learn/investigate what > Gradle is doing as part of running the task, and I want run the task > repeatedly to do so.
Does --dry-run not do what you need here? > Or, if you write a tutorial and people have to run a certain task, I want to > have a "deterministic result", i.e. the task should always execute, otherwise > I need to explain to people how they can get the build dirty (or do a clean) > in order to get the task to run. > > Etienne > > > > On 17.01.2011, at 10:32, Mathias Kalb wrote: > >> Hi Adam, >> >> I would not remove the "-a" even if the UP-TO-DATE check is optimized. It is >> a useful and working feature. >> >> Your ideas for the UP-TO-DATE check are very good. Is there a JIRA issue for >> this. >> >> I profiled the UP-TO-DATE and found, that a new compileJava was faster than >> the UP-TO-DATE check. >> >> I called "gradle clean" and then twice "gradle --profile build" and the >> first "compileJava" takes "2:11" and the second takes "2:14". >> >> So the UP-TO-DATE check really needs optimization. >> >> regards, >> Mathias Kalb >> >> >> Am 12.01.2011 00:33, schrieb Adam Murdoch: >>> >>> On 11/01/2011, at 7:40 PM, Mathias Kalb wrote: >>> >>>> Hi Adam, >>>> >>>> I often used the "-a" during my creation of the build scripts. >>>> >>>> I have a multiproject with project dependencies. >>>> >>>> If the first two subprojects works fine and the third has a problem I only >>>> want to build the third subproject "gradle -a :subproject3:compileJava". >>>> >>>> Without the "-a" gradle has to check the other two subprojects and the >>>> UP-TO-DATE check takes a long time (> 1 minute on a fast machine). >>> >>> I guess we'll have to keep -a for a while longer, then. >>> >>> Over time, we will make these up-to-date checks faster, so that eventually >>> -a ends up making no difference. There are certainly things we can do here. >>> For example: >>> >>> * Perform the checks asynchronously, so that we are invalidating queued >>> tasks while executing another task. >>> >>> * Aggregate tasks together and check only the inputs and outputs of the >>> aggregate, rather than intermediate files. For example, in the case of >>> project dependency, you generally only care if the jar is up-to-date wrt >>> its transitive inputs. You don't care if a class file has been deleted or >>> changed, as it is essentially a temporary file for the purposes of building >>> the jar. >>> >>> * Often, the output of one task is the input to another task (or tasks). We >>> can merge the checks into a single pass. >>> >>> * The daemon can listen for file system changes, and invalidate tasks in >>> the background. We should be able to end up with a pre-built model, with >>> the checks already performed. >>> >>> >>> >>>> >>>> Mathias Kalb >>>> >>>> Am 10.01.2011 22:08, schrieb Adam Murdoch: >>>>> Hi, >>>>> >>>>> There are a few command-line options which have been superseded by >>>>> incremental build, and I'd like to remove them. The options are: >>>>> >>>>> -A/--dep-tasks >>>>> -a/--no-rebuild >>>>> --no-opt >>>>> >>>>> Anyone have a reason to keep them? >>>>> >>>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
