On Thu, 17 Aug 2000, David Lee wrote: > [...] > I certainly prefer the simplicity of Andrew's in principle. My worry was > that it might not be flexible enough for portability. Perhaps I should > re-visit the whole problem again, and see whether I can quantify what > advantages that my "Approach 2" (with its undesirable extra complexity) > might have that really seem absent from "1" ... if any! > > You are making me defend my corner (i.e. "approach 2"). Excellent. So my > next step must be to re-examine whether (and if so, why) my corner is > worth defending in the first place. Following my message above, I have re-investigated what I was doing nearly five weeks ago (a long time, including two weeks distracting holiday). Reminder: 1. Andrew's proposal is to leave all the Makefiles alone, except for adding a line "include Make.Rules". This file is generated from its generic template "Make.Rules.in" by the local sysadmin running "configure" (itself derived and distributed, by the package maintainer, from "configure.in"). 2. Steve and I propose making all the Makefiles derived, by the local sysadmin, from their template "Makefile.in". We still continue to derive and use Make.Rules, exactly as in Andrew's proposal. Executive summary: Proposal "2" is a superset of "1": "1" is unchanged by the addition of "2". They achieve two different things. The addition of "2" should make no discernible difference for the average "small-site" sysadmin, but provides potentially large benefits for large, multi-platform sites. Detail: The main item, "1", we all agree, is for "Make.Rules" to contain the flags, options etc. for the local sysadmin at his/her local site. This is very similar to the existing "defs" stuff, but has the huge advantage of being derived automatically and (usually!) reliably by "configure". Both proposals/approaches maintain this: no change. But Steve and I go one step further. (For those folk running a private hobbyist environment, this consideration is probably largely irrelevant and unnecessary, but be assured that our proposal does not negatively affect your use.) Our proposal (which is standard, and indeed, recommended GNU autoconf behaviour to include) is mainly of benefit for those of us at much larger sites, maintaining software across several different platforms (mine is a relatively small university, but even we, in the last five years, have had simultaneously to maintain as many as seven different operating systems). It is highly advantageous to be able, if one wishes, to build the object files in directories away from the source directories, typically in a parallel directory tree, one tree per platform (linux-intel, linux-sparc, solaris-sparc, hpux10, ...). For example, at the top-level, create a new, empty directory "linux-intel", cd into it, and do "../configure". Note the double-dot in "../configure". We are in a new, virgin directory, and directory tree, with no "Makefile"s. As I see it, this is impossible under Andrew's suggestion. But this "Langasek-Lee amendment" augments Andrew's suggestion, to derive these required Makefiles in the new object directories, from source Makefile.in templates. It uses a fully approved (indeed, recommended) feature of autoconf and all falls neatly into place. Adding this functionality is exceedingly useful to multi-platform sites and does no harm to simple, hobbyist-type sites. The only required changes to add the second proposal to Andrew's original are: o Rename all Makefile to Makefile.in; o Minor edit to these Makefile.in to include lines defining $srcdir VPATH etc. o Adjust configure.in to include these Makefile.in in its AC_OUTPUT . Adding this amendment to Andrew's original should be unnoticed by existing users (except the observant might initially wonder why the distribution excludes "Makefile", but adds corresponding "Makefile.in"). But it could be a very big win for larger, multi-platform sites. I request (plead!) that we add this extra functionality, as, indeed, is recommended by GNU. There! That's my opening defence. I'm happy to listen to alternatives which can likewise both maintain existing functionality and also allow multiple independent object trees to be built. -- : David Lee I.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/~dcl0tdl South Road : : Durham : : Phone: +44 191 374 2882 U.K. :
