+1 too. Especially while debugging your builds, --no-opt is your friend. regards, René
Am Mo, 17.01.2011, 14:51, schrieb Etienne Studer: > +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 > > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
