On Wed, 16 Aug 2000, Andrey Savochkin wrote: > On Tue, Aug 15, 2000 at 03:29:34PM +0100, David Lee wrote: > > [...] > > Some confusion here, I think. Let's clear up some details. > > > > Approach 1: (Andrew Morgan): minimal change. The only Makefile to be > > changed (i.e. renamed into "Makefile.in" and minor editing) is the > > top-level one. All other Makefiles left alone. > > > > Approach 2: (Steve Langasek and me): change all Makefiles (rename and > > minor editing). > > > > In both cases the "minor editing" is to make certain "BLAH_1 = fixed_1" > > into "BLAH_1 = @variable_1@", so that configure can substitute the > > "@...@" tokens as it generates Makefile from Makefile.in . No extra > > complexity is introduced. > > David, I understand how autoconf works. > I definitely saw Andrew's words "creation of two files ... get included by > every makefile (Make.Rules)..." > It is a very short, exact, and descriptive explanation of the whole design. > I cheered this exact design, and pointed out why I like it. > > So, I think, we have 3 approaches there: original Andrew's supported by me, > and your #1 and #2. Thanks for the clarification. My description or representation of "Approach 1" was deliberately simplified to keep the message shorter: it includes the "Make.Rules" idea. It was (and is) meant to represent Andrew's ideas (as defined by him, rather than as (perhaps poorly) represented in my message). > Andrew's words implied that none Makefile contains "blah = @blah@" and that > we just generate proper Makefile includes (with prototypes of the include > files certainly containing "@blah@"s). > It's an analog of defaults.defs which is the only file needed to be > modified. Ah. OK. My representation of Andrew's idea (as "Approach 1") was faulty. (Not only was it many weeks ago that I was doing this: I've also had a nice holiday in the meantime, so my memory of that work is hazy!) Redefine: Approach 1: Andrew's. Detail: as defined by him. Approximate representation: autoconf adjusts as few files as possible, probably just one, "Make.Rules" (I had earlier said "top-level Makefile" and omitted "Make.Rules"). Approach 2: Steve Lanasek and me: autoconf adjusts all Makefiles (and also a "Make.Rules"). 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. Thanks for your thoughts and prompting me to action. -- : 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. :
