Big suggestion for developers.

Michael K. Neylon (mneylon@engin.umich.edu)
Mon, 24 Aug 1998 16:10:26 -0400


If you've been following the AS development recently, you know that I'm
using one to be tossing up RPMs for AS shortly after any release.  However,
I have yet to do so with 1.5pre9 because the current way that AS is 
distributed, it's becoming very inconvience to install AS via
a distribution manager.  

The biggest obsticle in this way is that the AS ./configure, unlike
most other GNU configures, asks questions of the user in order to set 
compile time options.  While this is fine for the people that do it
by hand, a program like rpm redirects the prompt and does not allow
the user to interact with any script programs that may be involved 
in building the rpm.  

What makes the current distribution of 1.5pre9 (last I checked) is that
the default configure.in scripts were gone, and the program used a
config.cache to setup things for the system - this is a major program
in letting the package manager build the package for itself.

Additionally, many of the options that are asked for during the ./configure
script are either 1) de facto arguements to any properly prepared configure
script (such as binary install location, etc.) or 2) what I would consider
Run Time Options (such as the default graphics viewer in order to set
the background).  Ideally, if the configure program was set up as most
other configure programs, then, for building the package distribution, I
would simply have to pass a series of path arguements to ./configure, then
patch run time config files to point to whatever might be necssary for the
particular distribution.

I do understand that what I might consider as canditations for runtime
options are used by the current source as compile time options (
the animations, for example).  And by turning some on or off, the program
will be more efficient/smaller/less memory intensive than with certain
options on.  However, I would argue that the point of a distribution package
is to provide the enduser with a set of default settings that might be
too much for the user, but will get the job done and will show off its
features rather than be the most efficient program out there (By using
a distribution like Red HAt in the first place, you are already giving
up some efficiency for the convience of the package manager amoung other
things).

So, my suggestion to the AS developers (and if you need help with some
of the semantics, I can try to do something), is to decide what 
options are truely runtime, and what are truely compile time.  Move
the runtime options to appropriate config files (most likely in /u/s/a/,
~/G/L/a).  Set up the configuration script to be able to prompt for
any compile time options, and choose reasonable defaults for those in
case the user doesn't specify or override them.  Get rid of any
interactivity in the ./configure script.

What will this do if done right?

- Expert users NOT using a distrubition will be able to build AS however
they like, with help for compile time options in the ./configure script.

- Non-Expert users with a distrbition and not too interested in 
modifying can use a package that has all the basic default values all
set up for them.

- Expert users with a distribution that might want to modify a few of the
default compile time options can easily modify *1* line (yes, 1 line)
in a package specification file, rebuild the package, and install their
customized package, instead of having to hunt and peck at patch files.

- Most importantly, AS will seem more professional.  As someone who 
likes to build/recompile his own programs, I know that when a large
package/distribution can be built & installed on *any* system without
patching the source, and with the simple "./configure; make; make install"
sequence, I know I'm dealing with a programmer(s) well versed in the ease
of unix distributions, and gives me a good feeling.  Seeing prompts asking
for user interaction gives me a feeling of a hack.

Mind you, I understand that AS is still in beta, and that all features,
both of the program and of the compilation process, might not be in
place.  However, I would highly recommend that a good look at the 
./configure script be placed high on the priority list.

(As an aside, I've been bouncing between WM and AS lately.  I'm on both
lists, and it surprises me the lack of complaints there are about the
multiple config files in WM, and in general, the global feeling
I get from WM users.  I think, besides the fact that there *is* a
GUI WM configuration program or two (which I do know is coming for
AS in the next major release), I think the more sophisticoated source
and compilation process that WM has leads to this.  I see very few people
complaining about problems compiling WM on their system (unless you get
to the other architechtures), but there have been numerous problems here
with AS.  Again, looking carefully at the configure script will be
a major point in relieving the problems that users have compiling
AS.)

-- 
Michael K. Neylon, UM ChE Grad  | "..Besides, as an engineer, I've
mneylon@engin.umich.edu         |  never actually spoken to [a woman]
A!, PatB, F!, MST, ST, DW       |  and the very thought gives me the
http://pinky.wtower.com/mneylon |  screaming willy-wallies!" Brain - A!#24

--
   WWW:   http://www.afterstep.org/
   FTP:   ftp://ftp.afterstep.org/
   MAIL:  http://www.caldera.com/linuxcenter/forums/afterstep.html