On Fri, Mar 26, 2010 at 12:59 PM, Chas Emerick <cemer...@snowtide.com> wrote: > > On Mar 26, 2010, at 12:59 AM, Per Vognsen wrote: > >> On Fri, Mar 26, 2010 at 11:50 AM, Chas Emerick <cemer...@snowtide.com> >> wrote: >>> >>> Because they're common processes that are ideally built once, and then >>> reused with minor variation. Library reuse is generally considered to be >>> a >>> good thing in software development, so it strikes me as odd that many >>> think >>> that such practices should stop at the build's edge, as it were. >> >> Reuse is great. Integration tends to hamper reuse. > > This is likely wading into a silly semantic dispute re: "integration", but > I'd say exactly the opposite. When libraries are easily accessible within a > common platform, it is easier to use them (assuming you are also > participating in that platform). JVM libraries *could* be dis-integrated > into separate executables or whatever, but that surely wouldn't encourage > their reuse. Please note that Maven plugins are entirely, thoroughly > optional -- you choose which ones to bring into your environment, exactly > analogous to choosing libraries to be reused in an application.
It's not semantic nitpicking. There's a clear-cut difference a piece of reusable code with a function that can be called to generate a bundled Windows installer based on a set of arguments versus something that only works as part of a build system like Maven. I never said they should be separate executables (that's a terrible fit for the JVM world). I mentioned that as an example of how composable systems are built in the Unix world. It's a good conceptual model. In the Clojure world, functions (not necessarily pure, though pure functions play an important role in idempotent building) are the obvious counterparts. > It's worth considering how things have played out in other contexts. Take > ant, where there *are* plugins for doing a variety of interesting things, > but because there is no baseline platform and mechanism for roping in those > plugins in a consistent way from environment to environment, they've seen > far, far less adoption and usage than the analogous maven plugins, where > composition and reliable configuration is enabled by a consistent platform > and defined points of integration. I can't comment on Ant as my experience in the Java world is limited to non-existent. >> To take one of your examples, if I want to bundle my classes and >> dependencies into a Windows installer, I will call a function in a >> library (or a command line program in the Unix world) that does that. >> That's it. It doesn't need to be part of the build system and >> shouldn't be. I can call functions in the build system to supply the >> relevant arguments. If the build tool and library is well designed, >> the added value of integration in this example should be >> infinitesimal. > > I'd ask: what *does* belong in a "build system"? Should compilation be > included (doesn't matter which language)? There are command line programs > to compile source files, so why bother with make, ant, etc.? No, compilation should not be included. You mention make; it is a macro language, dependency graph walker, shell executor and up-to-dateness checker. It doesn't do any compilation. It's very bare bones. It's not at all perfect but it's much closer to what I want from a build system than something like Maven. > Aside from that extreme example (certain suggested only for illustration), > how does your preferred approach fare when working with others, and vice > versa? Should we all write our own one-off build scripts, each one > different from the last, and require our collaborators to grok each one's > unique subtleties as needed? The same way it works with any well-written software. When I want to build the bundled Windows installer, I import the library (which knows nothing about my build system) and call a single function, passing along whatever configuration information is appropriate. Done. -Per -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
