On 28/01/2013, at 11:28 PM, Luke Daley wrote: > > On 24/01/2013, at 2:52 AM, Adam Murdoch <[email protected]> wrote: > >> >> 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. > > Hard to know where to draw the line in this discussion, but I think it's > worth hashing this out. > > My issue with “build item” is that it doesn't really convey that this is a > “created thing”. It's just an “item” which could be anything.
That's exactly right. A build item can be anything. It may be built or it may not. For example, a source set is-a build item. Some source sets live in version control and are never built. Some source sets are generated from some inputs (often source sets themselves). Some source sets are sometimes built and sometimes not, such as a set of generated portable C source code that must be generated using a tool that runs only on certain platforms and downloaded for other platforms. The key feature of a build item is that it is a consumable thing, not that it is a producible thing. > The term “artifact” (using the “i” variant because that's the predominant > version in US english) We should be using the 'i' variant. This is what I've been typing and I haven't gotten around to telling auto-correct not to change it to the 'e' variant. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
