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

[T.E.Dickey]

> > > 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.
autoconf's "configure" scripts all allow you to override/pre-set common
variables in the environment, e.g.,

        CC              (compiler)
        CFLAGS          (compiler-flags)
        LIBS            (libraries)
        CPPFLAGS        (c-preprocessor flags)

so if you've a non-standard configuration, it's easy to make a wrapper that
"fixes" the script.  (Of course, if the non-standard configuration happens
often enough, it's worth adding to the script).  I made the script look in the
places that I know about.

Arguably, /usr/local should be ahead of /usr for non-standard packages
such as ncurses and slang.  But "/usr/local" is just a convention.  I
remember talking with an AT&T engineer some time ago, who said (in effect)
why, of course /usr/local isn't a standard location, it should be /sbin
(or something like that).

> 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/>.  
...
> 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.
I don't see anything unusual there - the /usr/5lib stuff is a known
case (in fact my script looks for it).
 
> 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.
that "ncurses.h" file has to be 1.8.5, or before.
you really don't want to use ncurses from _that_ long ago (honest).

(as for mixing curses.h along the include path - it's never been a good
idea).  But you can recover:

        CFLAGS="-I/usr/local/include" \
        LIBS="-L/usr/local/lib" \
        configure --with-screen=ncurses
 
> 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
that's almost workable (you won't like the colors if you're picky)

> 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
(I've built with the bsd4.4 curses on Linux; do it every cycle.  It's
ugly -- no color -- but builds/runs correctly)

> 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?
uh.  I've answered a lot of mail from people who've installed ncurses on
a system by just copying the shared library (so they've got the wrong
header).  How much fixing do you want?
 
> 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.
maybe - the whole point of auto configure is to choose from one of the
known/possible standard configurations, allowing a lot of permutations.
The hard things can be overridden (and noted for enhanced scripts).

> Please take these obeservation as encouragement to further improve the
> configure mechanism.
I'll keep it in mind.

-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;