On Tue, 15 Aug 2000, Andrey Savochkin wrote: > On Wed, Aug 09, 2000 at 05:46:59PM -0700, Andrew Morgan wrote: > > I'm not pushing the autoconf stuff as hard as others. I had a scheme for > > using autoconf: see the Linux-PAM-0-72-autoconf branch on sourceforge: > > > > > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/Linux-PAM/?cvsroot=pam&hideattic=0&only_with_tag=Linux-PAM-0-72-autoconf#dirlist > > > > 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. A derived "Makefile" is almost identical to its source "Makefile.in". Under both approaches, they are very similar to the current "Makefile". So the only first-level difference between the two approaches is whether this is done to one Makefile or to all. 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.) Andrew, Steve, and I are (I believe) firmly convinced and unanimous that we must maintain the readability of the source code and the Makefiles, whilst ensuring full functionality and making it as portable as is reasonably possible. (Steve and I have also been involved in the "Samba" project where these aspects are crucial: the Samba maintainers want maximum functionality, maximum readability and maximum portability! A tall order, but because of good project management (human) and good use of "autoconf" (technical), Samba has achieved these goals to a remarkable level.) 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. ---- Incidentally, Andrew used the phrase "automated source generation". I think this may easily be mis-interpreted. Neither approach automatically generates any source (other than one or two generic ".h" files, for which both are equivalent). Both automatically generate some Makefiles, but these are really "template and minor edit" operations. One of Andrew's worries is a belief that "autoconf" requires extra "#if..." constructions into ".c" files. Steve and I believe this to be untrue. Rather, it is portability that, of necessity, introduces such extra "#if..." things. Put the other way around, the "#if..." are a byproduct (agreed, undesirable) of portability, not of autoconf. In fact, "autoconf" is actually beneficial, in that it helps control the proliferation of these undesirable byproducts. ---- Hope that clears up any misunderstanding. (And I hope I have represented both sides reasonably well!) -- : 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. :
