I have some questions on Chapter 73 Extending the software model.
Component all the way down: Is there a difference between a generated source and a generated binary? Not all source transformations go from text to binary, so I assume a “binary” can be a readable text file that serves as an input source to the next step. Is that supported?
In the new model, how do I model intermediate products in a multi-compiler chain, since the output products of a compiler becomes the input to the next compiler?
Example 73.2: What is the Document component modeling in the context of the example? In fact I have this question for all things being modeled in that example. Perhaps a diagram overlaying the Gradle model on top of thing being modeled would illustrate this best? E.g. which @Managed elements model which files in the source and so on.
Example 73.7: “Setting the language name is mandatory”. I don’t see where the language name is being set.
Example 73.10: Right above the code example itself, the sentence reads “This rule generates a MarkdownCompileTask task”. I think it should be “This rule generates a MarkdownHtmlCompile task”. Is that correct?
1 Like
The model for processing inputs into outputs can be represented by a simple transfer function:
input products -> process -> output products
To me there is no difference whether I am compiling code or running tests. I have input products, and I produce outputs with some process:
inputs -> compiler -> outputs
compiled code -> run tests -> test results
Whether input/output products are are human readable source or binaries is irrelevant. GNU Make models compilation (as well as testing for those who tried it) with:
target (output file): prerequisites (input files)
commands (compiler)
Gradle’s advantage is that it can track the all the inputs including command line arguments and compiler version if the build task lists them as inputs (whereas Make simply tracks the time stamp of input files). And after experimenting with @OutputDirectory, I find it more powerful than simple target files. The simplistic modeling of Make is relatively easy to grasp, and what I am really interested in is how to map the new Gradle software model to that transfer function above. Whether I throw code coverage into the mix or a different way of running tests, I am really only chaining transfer functions together, or adding inputs to an existing one.