On 30/10/2010, at 2:25 AM, Ross Sargant wrote: > Adam, > Thanks very much for the advice. I assume in your suggested approach that > > "destFile" would be marked as @OutputFile in CompileNative and > > "srcFile" would be marked as @InputFile in TiniConvert?
Yes > > I'm curious how gradle determines it has to run the "flashLibrary" task when > I run the "image" task without using "dependsOn" ? It doesn't yet. I'd like to add that. > What actually makes that work? The fact that @InputFile and @OutputFile point > to the same file object? That they point to the same file. > > > > On Thu, Oct 28, 2010 at 8:22 PM, Adam Murdoch <[email protected]> wrote: > > On 29/10/2010, at 5:25 AM, Ross Sargant wrote: > >> Hi! >> >> To learn some of the "ins & outs" of Gradle, I'm attempting to changeover >> and existing ant build process to a native gradle one. The build process is >> generating a binary image file which gets loaded on to a flash memory part. >> Its not a particularly complex build but it does call out to several >> external tools. In a nutshell the process is >> >> 1) Compile high level java code >> >> 2) Compile several different sets of assembly code into native libraries (1 >> output file per library) >> >> 3) Run a conversion program which glues the output of #1 and #2 together to >> produce the final loadable image file. >> >> I'm trying to make full use of the incremental build capabilities but I >> think I'm missing something in the "theory of operation". I defined a >> "CompileNative' task type using @InputFile and @OutputFile which handles >> calling the necessary tools. I then defined a task for each library I need >> to build. >> >> task('flashLibrary',type:CompileNative){ >> sourceFile=new File("${project.nativeSrc}/flash/FlashIOP.a51") >> } >> >> The incremental support is working great w.r.t to this task alone. If I >> change the source file, delete the output file..etc it rebuilds the library. >> Perfect. >> >> The final task which handles step #3 looks like this: >> >> task('image',type:TiniConvert,dependsOn [compileJava,flashLibrary]){ >> >> } >> >> My issue is that when I do a "gradle image" AND the flashLibrary is >> determined to be out of date and re-executed, the 'image' task does not >> execute (considered up to date) although it needs to execute again to >> incorporate the modified library. >> >> Now, I kind of understand this because my "TiniConvert' task does not >> formally mark the binary library files as Inputs. However, it seems better >> to me if the gradle task dependency engine could somehow handle that for me. >> Since 'image' is a dependent of 'flashLibrary' and flashLibrary was >> re-executed shouldn't that mean 'image' will re-execute as well or is that >> only true if I formally configure 'TiniConvert' with the output of the >> dependent tasks marked as @Input? > > You need to mark it as an @Input (or @InputFile, more likely?). > > Gradle could certainly infer that the flashLibrary is an input of the image > task. Or more generally, that a file produced by a dependency of a task is an > input for the task. But that's not necessarily true. It's very likely, but > not necessarily so. > > Instead, I would rather that we flipped things around, so that when you say > that the flashLibrary is an input of the image task, then Gradle can infer > that the flashLibrary task is a dependency of the image task. That is, you'd > do something like: > > task('flashLibrary', type: NativeCompile) { > destFile = flashLibOutputFile > } > > task('image', type: TiniConvert) { > srcFile = flashLibOutputFile // or srcFile = flashLibrary.destFile > } > > Using artifact dependencies such as this, rather than task dependencies, have > some advantages. They more accurately model the world: the 'image' task needs > a flash library as input, but it doesn't really care how that library is > produced. This gives Gradle some flexibility about how it builds the flash > library. It might build it on another machine. It might substitute in a > pre-built one it downloads from a repository, or another developer machine. > Or Gradle might give you a way to implement rules like: when I'm doing a > release, the flash library must be tested before it can be used as an input > to another task. > > > -- > Adam Murdoch > Gradle Developer > http://www.gradle.org > CTO, Gradle Inc. - Gradle Training, Support, Consulting > http://www.gradle.biz > > > > > -- > Ross Sargant > Software Engineer > p: 954-623-6015 x2108 > email: [email protected] > > TVR Communications LLC > 541 S. State Road 7,Suite 5,Margate, Florida,33068 > > http://www.tvrc.com > -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
