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. The term “artifact” (using the “i” variant because that's the predominant version in US english) implies something that is a result of action. On a conceptual level, I'm for not using artifact in dependency management land because it's usage there doesn't quite match it's meaning. In dependency management, how is “artifact” different to “file”? That's what it seems to be to me. The concrete “file” that is the end game. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
