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

Re: autoconf


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

> 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

If you're interested in another example, look at
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.) 

So, if you move all environment-specific assignments into a separate file,
you improve your results of simplifying the code by another 50%.

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

> 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

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