On 23/01/2013, at 8:44 PM, Luke Daley wrote: > > On 23/01/2013, at 4:34 AM, Adam Murdoch <[email protected]> wrote: > >> >> On 16/01/2013, at 5:06 PM, Adam Murdoch wrote: >> >>> Hi, >>> >>> To better support building Android apps (and other things), we want to >>> rework the jvm language plugins so that they can handle building multiple >>> outputs from a given set of source files. >>> >>> I've made a bit of a start on a spec here, but's pretty rough: >>> https://github.com/gradle/gradle/blob/master/design-docs/building-multiple-outputs-from-jvm-languages.md >>> >>> I need some suggestions for terminology: >>> >>> 1. A term for the things that Gradle builds. With this work, plus >>> publications, components, reports and distributions work that is happening, >>> we're starting to model more of the things that Gradle can build. It feels >>> like we should have a term for this. So far we've been calling these things >>> 'things' and sometimes 'outputs'. I kind of like the term 'build item' from >>> abuild. >> >> I'm going to stick with 'build item' for now, as a working name for this >> concept, until something better comes along. > > Why can't we say that a directory and its contents are an “artefact”?
We could. But a build item can be more than just a directory or a file. Some examples: * A shared c++ library build item on windows is made up of zero or more directories of header files, a .dll file, a .lib file, and a .pdb file. * A system c++ library on unix is made up of one or more header files in (say) /usr/include and a .so file in /usr/lib. * A Java source set is made up of zero or more filtered directories of files. A build item is also not just some set of files, but also has some associated meta-data model. To me, both these things stretch the term "artefact" a bit too far. I prefer "build item", which does not imply the wrong stuff, over "build artefact", which does. The downside is, of course, that "build item" doesn't imply the right stuff, either. However, this is our "object", so it's not completely terrible to use something quite general. Given that, "build object" might be another option. I'm not necessarily against "artefact". I don't think it quite captures the meaning, but it's not a bad option. To use it, we'd need to come up with a new name for "artefact" in dependency management land, because those are not one of these things. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
