Are there any other changes you'd make to my script at this point? I may blog about it. For instance, is there a reasonable/idiomatic way to merge the srcDir and outputDir fields with the annotation properties in Gradle 1.0? I half way remember you alluding to this during the class.
On Mon, Jun 25, 2012 at 5:32 PM, Luke Daley <luke.da...@gradle.biz> wrote: > > > > > On 25/06/2012, at 3:36 PM, Howard Lewis Ship <hls...@gmail.com> wrote: > > > > On Mon, Jun 25, 2012 at 2:51 PM, Luke Daley <luke.da...@gradle.biz> wrote: > >> >> >> >> >> >> So ... should I simply delete the output directory inside my doCompile() >> method? >> >> >> Yes, see the Compile task for example. >> > > I've changed over to this, deleting the output directory and regenerating > all from source, and it seems to work. I want to double check the "deleted > a source file" scenario, to make sure the Copy and Jar tasks do the right > thing as well. > > I suspect that I'll only end up with a few (dozen) CoffeeScript files > totally a couple of thousand lines, so I expect this to not be a terrible > problem. > > > Which might mean that this is a micro optimization in practice. > > BTW; is it valid to start a thread pool and do a lot of this compilation > in parallel, as long as the pool is shutdown before leaving the method? It > seems to me that most of the time being spent is going to be disk I/O > reading and writing the source files. > > > Completely valid. > > Of course, what I really should do is compare timestamps on the output > file to decide if I need to compile the input file at all. > > > Timestamps aren't good enough as they can lie. That is, they are not > enough to guarantee that you don't need to recompile. You ultimately have > to compare against the previous run. Fine grained incrementalness is more > challenging than it first appears. > > > >> >> Given the message in the console output above, it seems like there could >> be a notification to a task that an input file was deleted and it should >> ensure the corresponding output file(s) are deleted. >> >> >> That would prevent the task doing any fine grained incrementalness and >> would be too presumptuous. >> > > True, but the callback could be optional or advisory; an extra annotation > on a method that says: "this source file was deleted"; the method would be > responsible for identifying the corresponding output file. > > > Which files have been removed since last time is also the kind of richer > (along with what's new or changed) information we will provide in the > future. > > It won't be enough to just use this though. You will also have to cross > reference with how the outputs have changed. > > >> But if I want a more "incremental" style, am I expected to walk the >> output directory and delete anything that doesn't have a corresponding >> source file? >> >> Yes, Gradle can't know the mapping here as it is specific to what the >> task is doing. >> >> In the future, Gradle will be able to give you info on what changed but >> you will still have to do some work. For cases like this though that are >> one to one it will probably be little. >> >> And, is there a base class to extend from that handles more of this for >> me? SourceTask doesn't seem to do quite what I want. >> >> >> No, SourceTask is your best option right now. >> >> FYI - the nightlies have coffee script compilation support and this will >> be experimental in 1.1. There is no commitment at this stage on when this >> will be non experimental. >> >> >> Thanks in advance for any guidance. >> >> $ gradle --version >> >> ------------------------------------------------------------ >> Gradle 1.0 >> ------------------------------------------------------------ >> >> Gradle build time: Tuesday, June 12, 2012 12:56:21 AM UTC >> Groovy: 1.8.6 >> Ant: Apache Ant(TM) version 1.8.2 compiled on December 20 2010 >> Ivy: 2.2.0 >> JVM: 1.7.0_04 (Oracle Corporation 23.0-b21) >> OS: Mac OS X 10.7.4 x86_64 >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> >> > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
