🚀 go-pugleaf

I like this list.  It doesn't leave much out and yet still covers the
things *I* think are important  :-).

In article <4743@m1.cs.man.ac.uk> zlsiial@cs.man.ac.uk (A. V. Le Blanc) writes:

   In article <1992May11.203911.21688@u.washington.edu> donn@carson.u.washington.edu (Donn Cave) writes:
   >I see in the GNUS bulletin that there's thought of unifying "configure".
   >Anyone else have any favorites among the various GNU configures?

There is talk of merging the various configure's.  I even have a
design.  Djm & I have been talking and we're both moving our assorted
configure's closer to a point that we think will make a combined
system easier to implement.

There is also a mailing list specifically dedicated to configure
related issues.  If you are interested, send mail to
configure-request@cygnus.com.  I've also got a reasonable log of past
discussions if you'd like some context.

   The features I would like to see in the ideal GNU configure are these:

   (1) It should be easy to use when compiling for an already
	supported system.  There is a slight problem with the
	fileutils, etc.,

These configure scripts are generated by a program called autoconf.
Autoconf has been going through some revision recently in preparation
for a release.

        in that they are awkward when, for example, include files are
	not in the expected places, or when the C compiler requires
	special arguments to work properly.  I have had a lot of
	trouble when compiling for systems whose libraries contain
	known bugs, which I can avoid, but which the configures
	cannot.  The gdb/binutils style is not bad here.

These programs, also libg++, use a configure written primarily by me
at Cygnus.  We call this one Cygnus configure.

        The patch/perl style is quite good.

These are configured by Larry Wall's metaconfig.

Personally, I also find it some small bother that autoconf (fileutils
style) must test for features each time it is run.

   (2) It should be adaptible for cross-compilation.  The fileutils,
	etc., configures are hopeless at this.

There is actually an argument that autoconf generated scripts can do
this job if they are handed a pointer to the cross compiler that will
be used.  Some of the more obviously necessary changes for this have
gone into autoconf recently.

        The gdb/binutils style are of course designed for this.  The
        patch/perl style do not work.

Although metaconf could perhaps be extended in precisely the same way
as autoconf.

   (3) It should at least document how one may add support for a new
	system.  From this point of view the fileutils, etc., and the
	patch/perl are good, while the gdb/binutils style are
	frightful.  Even with gcc, it is pretty horrendous styling it
	for a new OS on a known processor.

Uh, you've seen and read configure.texi, yes?  And you still find it
frightful?  Does this come from the configuration approach or is it
more related to the code itself?

I'm not looking for a fight, I'm looking for more specifics on how to
make it better.

   (4) I should also like to see better ability to evade some of the
	excesses which pervade GNU Makefiles.  I approve of the desire
	to see everything compiled with '-g', for example, but there
	are two important cases where this is simply inappropriate:
	(1) where space is at a premium; and (2) where the '-g' option
	is an error, as when compiling with gcc on many common
	platforms.

I've recently made changes suggested by rms to many of the gnu
makefiles to support precisely this change.  Expect to see them in
upcoming releases.  In short, CFLAGS now defaults to "-g".  Therefor,

	make CFLAGS=

Should allow building without -g, or will soon.

Otherwise, most, but not all, of the "excesses" appear necessary to
me.  I'll be happy to explain why if you'd like to name them.  If
these things aren't explained in standards.texi, then perhaps they
should be.

   (5) I am surprised that there is such little consistency in the use
	of certain -D options; for example, -DUSG in some GNU
	utilities may mean 'use strchr instead of index', in others
	'don't use bcopy, bzero, etc.', but in some it seems to assume
	the presence of numerous SYSV features.  Perhaps there ought
	to be mention of this (with suggestions) in the standards
	documents.

Because of the way GNU programs are maintained, that is, by disparate
developers all over the world, this isn't exactly possible.  Given the
current goals of the GNU project, I'm not sure it's necessary yet.

Until such time as the entire suite of programs is maintained as a
*system*, it probably isn't really much of a problem.  Cygnus is
attempting to maintain some set of GNU (and other) programs as a
system.  We've run into many of these issues.  In some cases we
propose solutions, in others we realize that keeping literally
hundreds of disparate maintainers in sync isn't strictly possible.


Some other items on my list are:

(6) Must scale.  configuring N programs should still require precisely
    one configure command, and should take less than order N time.
    Cygnus configure handles this now, including the ability to call
    any script that meets the standards.texi guidelines.

(7) Must bootstrap easily.  By which I mean that it should require as
    few other programs as possible.  If I'm crossing into a new
    system, I want configure to work very early on in the bootstrap
    process.  This is part of the reason that most configure's are
    shell based.  Most configure's address this to varying degrees of
    success.

(8) Cross configuration would be nice, but isn't critical.  ie, (on
    sun4: configure decstation).