lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV 2-8 help: Help!


From: Jonathan Sergent
Subject: Re: LYNX-DEV 2-8 help: Help!
Date: Fri, 6 Mar 1998 23:14:54 -0500

(note: I'm cc'ing this since I think it will take a while for my post to 
       get to LYNX-DEV.)

Henry writes:
 ] I have edited "#define LYNX_CFG_FILE" in userdefs.h _before_ running
 ] configure to set the compiled-in location of the lynx.cfg file that Lynx
 ] should read by default (i.e., barring a command line option or env variable
 ] set by the user).  I have set "--libdir" option when running configure to
 ] the place where I want to save (only save, not use) the distribution/sample
 ] copy of lynx.cfg, i.e., the lynx.cfg file placed in the top directory of
 ] the distribution breakout.  It has been working fine this way since the
 ] beginning of autoconf.

That's not how it is supposed to work.  This is what's really weird.
There is (ignoring the DOSPATH stuff):

   v
#ifndef LYNX_CFG_FILE
#define LYNX_CFG_FILE /usr/local/lib/lynx.cfg
#endif

in userdefs.h ... and lynx_cfg.h defines LYNX_CFG_FILE (used to be
--with-lynx-cfg=/path/to/foo/lynx.cfg, now is --libdir=/path/to/foo 
so that the LYNX_CFG_FILE define jives with what make install does).

The only reason for the userdefs.h entry is for other platforms without
autoconf.  There's no way that userdefs.h should be (or could be)
overriding the lynx_cfg.h file without at least a redefinition warning.

That is so weird about the whole thing.  When I get this behavior I
can do a clean build and get the proper behavior back again.  I will
try following the INSTALLATION instructions strictly as apparently two
people who do so are getting the same behavior.  Is -DHAVE_CONFIG_H not 
getting into src/makefile somehow?  That would certainly have other 
symptoms as well.

 ] What you seem to be saying is that you have "fixed" this behavior so that
 ] now "--libdir" sets "#define LYNX_CFG_FILE", and that setting overrides any
 ] editing of that define I may have done in userdefs.h.  Therefore to get the
 ] behavior I want [own customized lynx.cfg file to be read by default from
 ] a non-standard directory, i.e., different from /usr/local/lib] under the
 ] protocol you have implemented, I should copy my customized lynx.cfg into
 ] the top directory overwriting the distribution one, set the "--libdir" option
 ] to the directory I want to have lynx.cfg, and then do "make install."

This was the way it was from the start with ``--with-lynx-cfg=something''
in my understanding.  Setting the location of a configuration file is
a very autoconf desirable thing to do.  The reason it was switched from
--with-lynx-cfg to --libdir was that one had to manually specify --prefix
and --with-lynx-cfg, the --with-lynx-cfg value was not automagically set
from --prefix.  Furthermore, setting --with-lynx-cfg did not automagically
set the place where lynx.cfg would be installed (you had to use --libdir
to do that).

You can of course run make install and edit the installed lynx.cfg, or
run lynx with lynx.cfg in the cwd prior to installing a config file at
all, or any number of other things.  I always thought making Lynx look
for its config file in sensible places, like this order:

 * -cfg value,
 * $LYNX_CFG,
 * compiled-in location, 
 * same dir the binary is located in at runtime, 
 * runtime-binary-location-dir/../lib/lynx.cfg,
 * current working directory,
 * /usr/local/lib/lynx.cfg,
 * /usr/lib/lynx.cfg,           (Some Linux distributions put it here)
 * /etc/lynx.cfg                (Red Hat Linux 5 puts it here)

would be a good idea and wouldn't require people to rebuild the thing
or start using environment variables if they wanted to relocate the 
config file.  This is how Mozilla does it AFAIK -- it primarily looks
in $MOZILLA_HOME for its friends but it then checks 
/usr/local/lib/netscape/ and various other places before complaining.

Another possibility would be taking "can't find lynx.cfg" to be the
same as "empty lynx.cfg" i.e. all of the defaults.  This is also
friendly.

Will submit patch for either if people want it, but not for 2.8.  
Don't let this delay the release.


-- 
Jonathan Sergent / address@hidden

reply via email to

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