[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: autoconf



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.                  :





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []