+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. 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
