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

Re: autoconf

On Thu, 17 Aug 2000, David Lee wrote:

> [...]
> I certainly prefer the simplicity of Andrew's in principle.  My worry was
> that it might not be flexible enough for portability.  Perhaps I should
> re-visit the whole problem again, and see whether I can quantify what
> advantages that my "Approach 2" (with its undesirable extra complexity) 
> might have that really seem absent from "1" ... if any!
> You are making me defend my corner (i.e. "approach 2").  Excellent.  So my
> next step must be to re-examine whether (and if so, why) my corner is
> worth defending in the first place.

Following my message above, I have re-investigated what I was doing nearly
five weeks ago (a long time, including two weeks distracting holiday).


1. Andrew's proposal is to leave all the Makefiles alone, except for
   adding a line "include Make.Rules".  This file is generated from its
   generic template "Make.Rules.in" by the local sysadmin running
   "configure" (itself derived and distributed, by the package maintainer,
   from "configure.in").

2. Steve and I propose making all the Makefiles derived, by the local
   sysadmin, from their template "Makefile.in".  We still continue to
   derive and use Make.Rules, exactly as in Andrew's proposal.

Executive summary:

Proposal "2" is a superset of "1": "1" is unchanged by the addition of
"2".  They achieve two different things.  The addition of "2" should make
no discernible difference for the average "small-site" sysadmin, but
provides potentially large benefits for large, multi-platform sites.


The main item, "1", we all agree, is for "Make.Rules" to contain the
flags, options etc. for the local sysadmin at his/her local site.  This is
very similar to the existing "defs" stuff, but has the huge advantage of
being derived automatically and (usually!) reliably by "configure".  Both
proposals/approaches maintain this: no change. 

But Steve and I go one step further.  (For those folk running a private
hobbyist environment, this consideration is probably largely irrelevant
and unnecessary, but be assured that our proposal does not negatively
affect your use.) 

Our proposal (which is standard, and indeed, recommended GNU autoconf
behaviour to include) is mainly of benefit for those of us at much larger
sites, maintaining software across several different platforms (mine is a
relatively small university, but even we, in the last five years, have had
simultaneously to maintain as many as seven different operating systems). 

It is highly advantageous to be able, if one wishes, to build the object
files in directories away from the source directories, typically in a
parallel directory tree, one tree per platform (linux-intel, linux-sparc,
solaris-sparc, hpux10, ...).  For example, at the top-level, create a new,
empty directory "linux-intel", cd into it, and do "../configure".  Note
the double-dot in "../configure".  We are in a new, virgin directory,
and directory tree, with no "Makefile"s.

As I see it, this is impossible under Andrew's suggestion.  But this
"Langasek-Lee amendment" augments Andrew's suggestion, to derive these
required Makefiles in the new object directories, from source Makefile.in
templates.  It uses a fully approved (indeed, recommended) feature of
autoconf and all falls neatly into place. 

Adding this functionality is exceedingly useful to multi-platform sites
and does no harm to simple, hobbyist-type sites.  The only required
changes to add the second proposal to Andrew's original are:
o  Rename all Makefile to Makefile.in;
o  Minor edit to these Makefile.in to include lines defining $srcdir
   VPATH etc.
o  Adjust configure.in to include these Makefile.in in its AC_OUTPUT .

Adding this amendment to Andrew's original should be unnoticed by existing
users (except the observant might initially wonder why the distribution
excludes "Makefile", but adds corresponding "Makefile.in").  But it could
be a very big win for larger, multi-platform sites.

I request (plead!) that we add this extra functionality, as, indeed, is 
recommended by GNU.

There!  That's my opening defence.  I'm happy to listen to alternatives
which can likewise both maintain existing functionality and also allow
multiple independent object trees to be built.


:  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] []