On 19.01.2011, at 00:07, Adam Murdoch wrote: > > 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? >
No. Since the actions are not executed, the output is different (i.e. smaller) with the --dry-run option. Not being able/allowed to force Gradle to run a certain task would be quite a constraint, I find. And, in my opinion, having such a constraint would not match the Gradle mind-set. >> 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 > Etienne Studer Senior Software Developer Canoo Engineering AG Kirschgartenstrasse 5 CH-4051 Basel T +41 61 228 94 44 F +41 61 228 94 49 [email protected] www.canoo.com
