LYNX-DEV Autoconf plans

[Jim Spath (Webmaster Jim)]

Based on several notes asking about how autoconfigure fits into
Lynx development, here are my views on the directions we're heading.
Again, Tom is doing most of the work and has some comments on this at
http://www.clark.net/pub/dickey/lynx/lynx-autoconf.html

The notes:

Wayne Buttles:
> Does this mean you are not done yet?  Also, have you put in the last
> couple fixes from Fote since you picked up the code?

Larry W. Virden:
> >are things like LOCAL_DOMAIN, HELPFILE and such. Is there an easy way
> >to automate such?
> I always liked the way some systems did this by 'including' a file.local
> that overrode the default values, instead of editting files.

Subir Grewal:
> 2. Having 'make install' install the lynx_help heirarchy as well.  I
> realize this might be problematic since it would mean getting the path
> right in both userdefs.h and lynx.cfg (perhaps a command line option

Other comments from WIN and VMS users have been "what about us?"

config.h
--------
This file is created by the configure script and contains platform
specific definitions.  This will be mostly for UN*X systems.  The
other platforms will need pre-built config.h files.  We might name
these config.h-mswin, config.h-vms, etc.  This replaces the old
scheme of multiple makefile targets with multiple library makefiles.
If configure is done right, users don't need to edit config.h.

Configure should find the location of system programs such as sendmail,
zip, and viewers like xli, etc.  Environment variables can be checked
for TMPDIR, WWW_HOME; the local domain should be determinable.

The options to configure can be used to set compile-time choices:

     --with-PACKAGE[=ARG]
     --without-PACKAGE
     --enable-FEATURE[=ARG]
     --disable-FEATURE

As this is really the last step in Tom's plan, it's not in there. 
However, users are more interested in this than building Lynx for another
platform, so comments are welcome on this aspect.  "Keep it simple."  I
could see creating several template configure scripts, e.g., one for
multi-user anonymous Lynx, one for single-user non-anon, etc.  They might
look like this: 

./configure \
  --with-screen=ncurses \
  --with-numbered-links=on \
  --with-help-dir=/usr/local/lynx2-8/ \
  --with-global-mailcap=/usr/local/lib/lynx/mailcap \
...

The options can then be rearranged so that the important ones for that
flavor are up-front, instead of changing config.h or userdefs.h

The switches may also include install directories.  Configure will assume
defaults for these otherwise. 

userdefs.h
----------

Configure should be used for platform stuff, but I think we will still
need userdefs.h for some user-specific stuff.  The location of the
run-time configuration file might be an example of something a user might
want distinct from the system default. 

Info on autoconf says this:

   Some software packages require complex site-specific information.
Some examples are host names to use for certain services, company
names, and email addresses to contact...
   Such site configuration information should be put in a file that is
edited *only by users*, not by programs.  The location of the file can
either be based on the `prefix' variable, or be a standard location
such as the user's home directory.  It could even be specified by an
environment variable.  The programs should examine that file at run
time, rather than at compile time.  Run time configuration is more
convenient for users and makes the configuration process simpler than
getting the information while configuring.  

lynx.cfg
--------
I've tried a few ideas on how to update lynx.cfg from the "old" one
and have had little success.  This still needs work.

Systems
-------
We need those alpha testers to try this out on all the systems Tom
and I don't have, particularly SCO, HP, AIX, and DEC boxes.

Code changes
------------

Tom has done yeoman's work merging Klaus's, Wayne's and Fote's code for
the last two months.  We need a stable base for this, but so far, there is
no "source tree".  Playing tag with our code base is a lot more work.  I
had thought to call one of these 2.7.1, the next 2.7.2, but so far it
isn't stable enough. 

------
<http://www.cs.indiana.edu/picons/db/users/us/md/lib/bcpl/jspath/face.xbm>
But I'm quite used to being humiliated;
I can even go and stick my head in a bucket of water if you want...

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;