lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV New code for testing


From: Larry W. Virden, x2487
Subject: Re: LYNX-DEV New code for testing
Date: Wed, 23 Apr 1997 08:42:07 -0400

> > Here are some comments:
> > I configured it as followed:
> >     configure --with-screen=slang --prefix=$HOME
> > It configured and built fine, but when I ran it it looked for lynx.cfg
> > in /usr/local/lib instead of $HOME/lib.  I think if configure is going
> > to intall things in $prefix/{bin,lib,man} then it should also configure
> > the software to build that way so you don't have to edit userdefs.h.
> 
> Seems reasonable that the location should be set consistently 
> *as a default*, but it could not replace the requirement
> that the installer have a look at the configuration files and edit
> them if appropriate.  There are just to many things that can be
> set differently, and moving them all from the files to the ./configure
> command line (which then would manipulate the files) somehow doesn't
> seem to make sense.


1. I have noticed that configure creates "makefile" (lower case m) and
there is a "Makefile" (upper case m) which remains unchanged - which
installs things into /usr/local.  Some make's when faced with 2 files
of the same name, differing only by case, make a choice of one.  I
recommend that the Makefile be renamed to Makefile-noconfig or some
such thing.

2. I agree with the original poster that at the very least, if configure
takes an argument, that that value be used in all places appropriate including
the userdefs.h.

What I've thought in the past as being desireable would be a 
separation of userdefs.h and defaults.h .  userdefs.h, which would not
appear in the distribution, would be either an empty file, or contain
all the defines a user wished to override in defaults.h .  defaults.h would
#include userdefs.h first, then #ifndef all the defines in the file so
that anything the user specified would override.

In this way, the user can change the file one time, leave it in place,
run patches against the distribution, and not worry about overwriting
his/her localizations. 

The only other two files in the past I've had a need to localize were the
Makefile and lynx.cfg;  Since the makefile is now generated, that is mostly
taken care of (except for the case where someone has to modify it to
handle local flags, etc.) and lynx.cfg could be distributed as lynx.cfg-dist
perhaps.

> > Also, when you unzip the source, it puts everything in lynx2-7-1/
> > It'd be nice if it unpacked in lynx3.0 or something so it wouldn't
> > clobber my old source.
> 
> I think for others that is a feature.  Since I sometimes make .zip's that
> only contain the new or changed fiiles, for those it is a requirement.
> You can simply create a (sub)directory somewhere else and start from there
> if you have a lynx2-7-1/ which you don;'t want to change.

I see a use for both - in the case of a development version, considered
experimental, a new directory name would be useful.  For distribution
of patches needed against a release version, using the same name would
be useful - particularly with the above mentioned renamings performed.

-- 
Larry W. Virden                 INET: address@hidden
<URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
Unless explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]