Hello, On Tue, Aug 15, 2000 at 03:29:34PM +0100, David Lee wrote: > On Tue, 15 Aug 2000, Andrey Savochkin wrote: > > > On Wed, Aug 09, 2000 at 05:46:59PM -0700, Andrew Morgan wrote: [snip] > > > which autoconfs the creation of two files in the top level directory, > > > which get included by every makefile (Make.Rules) and c-files > > > (pam_aconf.h). This sort of mirrors the defs/* file approach we have at > > > present and reflects my general bias against having too much automated > > > source generation, but uses autoconf to do local configuration. > > > > I definitely prefer this approach. > > The reason is that it makes makefiles more readable. > > At my opinion, makefiles are the face of a project. They should be > > readable, simple and close to what they really should do as much as possible. > > 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. [snip] > So the only first-level difference between the two approaches is whether > this is done to one Makefile or to all. 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. If you're interested in another example, look at ftp://ftp.nc.orc.ru/pub/Linux/people/saw/pniam/pniam/pniam-0.05.tgz it's only top level Rules.make file that needs to be touched by autoconf. Certainly, module authors may keep their own autoconf stuff in whatever style they prefer, but I don't think we should force all makefiles to be `configured' by autoconf. > > Now to readability and simplicity of Makefiles (as you say, the "face" of > the project). I totally agree that source code, including Makefiles, > should be as readable and simple as possible. > > Not only does the "autoconf" process maintain both readability and > simplicity of Makefile (or Makefile.in), it can actually simplify them and > the source code. (For example, my own "Makefile.in" files are now not > only considerably simpler and more readable, but also considerably more > portable than the 0.72 "Makefile"s.) Excellent! So, if you move all environment-specific assignments into a separate file, you improve your results of simplifying the code by another 50%. [snip] > In Linux-PAM Andrew differs from Steve and I only in how best to achieve > all these: > > 1. Andrew is going for a "minimal change now", to minimise the risk of > autoconf breaking anything during the transfer. > > 2. By contrast Steven and I are going for a "whole hog now", which gives a > slightly greater risk of breaking something during the transfer, but, we > believe, gives a greater longer-term payoff in both portability and > readability after any such initial wobble. That's not the question of temporary breaking something. I definitely believe that auto-modified makefiles are not so good that makefiles that include configuration parameters. If Andrew meant what he really said, he, probably, believe so, too :-) [snip] > Hope that clears up any misunderstanding. (And I hope I have represented > both sides reasonably well!) The discussion is ok, although, there was no misunderstandings... Best regards Andrey
