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

Re: autoconf



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





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