On Tue, Nov 16, 2010 at 12:31 PM, Mattmann, Chris A (388J) <[email protected]> wrote: > Hmm, my 2 cents is that it's infinitely simpler to understand a build.xml > file (or better yet a Maven pom.xml :) -- just my opinion people no > tomatoes!) than it is to understand makefiles, or better yet, programs that > generate makefiles on the fly, or that generate other build scripts on the > fly etc etc.
I much prefer Make to all alternatives. Lucy is at base a C project, and Make is the standard for C. Certainly other things can work, but most anything else causes me about the same amount of alarm as a project that has only a README.doc in Word format. > Ant is available on nearly every Linux distribution that I've come across in > recent years (installed into /usr/bin/ant or some variant). I don't recall the details, but I recently tried to install Ant on my current desktop (Linux Slamd64) and gave up. I'll do it from source at some point, but think it's silly that I'm not able to make updates to the Lucy project page until then. My initial impressions of Ant are hence quite negative. > That said, these are just my preferences (as are Marvin's for Make/programs > that generate makes and so forth :) ). What do others think? The key question > to ask yourselves is: > > 1. will Marvin be the *only* RM that this project ever sees? Had to look up RM. No, presumably there will be other Release Managers so that Marvin can spend his time on areas more demanding of his particular expertise. > 2. will Marvin be the *only* person building this project, ever? No, I presume that some significant percentage of users will be building this. The bar should be pretty low, roughly equivalent to 'make config; make all; make install'. > 3. of the 2-3 existing Lucy developers, what are the preferences? I know > Marvin's: what about Peter/Nate? Make without reliance on autoconf or other impenetrable junk. The general approach Marvin is currently using seems fine, although removing reliance on Perl seems good. I want something short that can be clearly understood in it's entirety. --nate ps. My feelings on Make are reasonably echoed here: http://blog.jgc.org/2010/11/things-make-got-right-and-how-to-make.html
