LYNX-DEV auto config experiences (was: New development code)

[Klaus Weide]

On Thu, 13 Mar 1997, Jim Spath (Webmaster Jim) wrote:
> On Thu, 13 Mar 1997, Larry W. Virden, x2487 wrote:
> 
> > how do you wish errors reported for this package?
> 
> To this list, eh?  Plus, be sure to include OS name, CPU, stuff like that.
 
> > I tried using the configure to see if that was needed to set things
> > up.  Unfortunately, I had to set an export CC, as I couldn't get configure
> > to respect my --without-gcc argument.  Even then, I got stuck:
> > export CC=cc
> > ...
> > checking for ncurses header file... configure: error: not found
> 
> > I have _no_ idea how to tell configure where my curses (or the slang
> > for that matter) are installed.  When I did the configure --help I didn't
> > see that info as an option.
> 
> You should first try the vanilla "./configure" to see what the script does
> without options.  That should be the general case.  Tom and I are still
> working on the various permutations of curses and ncurses dir locations. 
> The script will find stuff; you should not need to specify locations, only
> choices of features. 

Here is my experience with the auto configure script.  I actually did the
test compilation (which went fine after some tweaks) yesterday before
uploading to <URL:http://sol.slcc.edu/lynx/klaus/merged/all/>.  

huitzilo:~$ uname -a
SunOS huitzilo 4.1.3_U1 6 sun4m

This machine has a (maybe pathological) collection of various *curses
header and library files scattered over different places:

huitzilo:~$ ls -l /usr/*/*lib/*curs* /usr/*lib/*curs*
-rw-r--r--  3 root       242342 Jan 20  1994 /usr/5lib/libcurses.a
-rw-r--r--  3 root       266458 Jan 20  1994 /usr/5lib/libcurses_p.a
-rw-r--r--  1 root        52416 Jan 20  1994 /usr/lib/libcurses.a
-rw-r--r--  1 root        57140 Jan 20  1994 /usr/lib/libcurses_p.a
lrwxrwxrwx  1 root           27 Jan 22  1996 /usr/local/lib/libcurses.a -> 
/usr/local/lib/libncurses.a
-rw-r--r--  1 root       333018 Jan 22  1996 /usr/local/lib/libncurses.a
-rw-r--r--  1 bin        450098 Jun  6  1994 /usr/local/lib/libpcurses.a
-rw-r--r--  1 root        52416 Jan 20  1994 /usr/ucblib/libcurses.a
-rw-r--r--  1 root        57140 Jan 20  1994 /usr/ucblib/libcurses_p.a
huitzilo:~$ ls -l /usr/*/*include/*curs* /usr/*include/*curs*
-r--r--r--  1 root        23646 Jan 20  1994 /usr/5include/curses.h
-r--r--r--  1 root         5270 Jan 20  1994 /usr/include/curses.h
-rw-r--r--  1 root        52505 Jan 22  1996 /usr/local/include/curses.h
-rw-r--r--  1 bin         17814 Jun  6  1994 /usr/local/include/ncurses.h
-rw-r--r--  1 root        10825 Dec 12 17:08 /usr/local/include/slcurses.h
-r--r--r--  1 root         5270 Jan 20  1994 /usr/ucbinclude/curses.h

Note that this isn't a constructed example, but a real life provider's
shell machine (and I am just a user and cannot change the setup).  So
I suspect there might be others like that.

As I expected, the configure script didn't fare too well with this
bewildering choice :).  I wanted --with-screen=ncurses.  ./configure
did its thing and didn't report any errors, but its tests were done
against the wrong .h file.  compilation thereafter failed.

Of the files above, /usr/local/include/curses.h is the newest one (It
says #define NCURSES_VERSION "1.9.8a", I have to take what I can get) and
the one that corresponds to /usr/local/lib/libncurses.a.  So that is what
I wanted to compile with (and ideally, configure should have figured that
out :)).  I managed by creating a ~/include directory and putting some
strategically placed symbolic links there, then editing the configure
script so that it now has

        for cf_incdir in \
                $HOME/include \
                $HOME/include/ncurses \
                /usr/include \
                /usr/include/ncurses \
                /usr/local/include \
                /usr/local/include/ncurses
        do
                for cf_header in \
                        curses.h \
                        ncurses.h

but this is hardly the recommended way...  Compilation then worked
(configure was passing something equivalent to -I~/include to the
generated makefile, as expected).

To summarize, Jim says:
> The script will find stuff; 

and I say:
But it will not always find the best choice, it will just find something.

I suggest that /usr/local/include files should be checked before
/usr/include files.  (If there are several versions of headers flying
around, the later version will typically be in /usr/local/... especially
for add-on packages like ncurses, but I may be wrong.)  
Even better - if this is possible at all - try to make compilation use
a libncurses from /usr/*local*/lib if the .h file was chosen from
/usr/*local*/include.  And if the automatic choice doesn't always work
(which we can safely assume) give a way to override.

In the current setup, the script
 - does not make sure that the flags and include directories effective
   for compiling Lynx are the same ones as for the ./configure testing
   (the -DNCURSESHEADER hack is not always sufficient)
 - probably the same for -l libraries (maybe needs to set -L directory
   depending on outcome of ./configure testing)

> you should not need to specify locations, only
> choices of features. 

That's nice in theory.  But if the theory breaks down for some reason,
there should be a way to give hints to configure so that it makes
better choices about location.  (or to just override the choice it makes).

It may seem that finding locations for {,n}curses.{h,a} files shouldn't
get mare special attention than other files; but that is the one thing
that has generated a lot of mail from users to lynx-dev.  If the
configure mechanism could be made intelligent enough to have good
heuristics for this (and a way to override) even for unusual setups, that
would be a big step forward.

Just for fun, I also tried to configure and compile an Linux *without*
any --with-screen=...  That also failed.  There were old (non-ncurses)
curses.h files on the system.  It seemed ./configure and the Lynx
compilation did not agree an which ones to use.  (I didn't pursue this
further).  Since undoubtedly many people will just run ./configure
without reading the documentation, shouldn't --with-screen=ncurses be the
default for Linux, or at least an explicit --with-screen=oldcurses be
required for Linux?

It could be argued that theses systems are sufficiently broken that
./configure cannot be expected to work on them.  Wee I suspect there are
a lot of systems "broken" like that out there, and if all components on
all machines were installed in their standard places, there probably
wouldn't be any need for auto configure.

Please take these obeservation as encouragement to further improve the
configure mechanism.

  Klaus




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