Re: readline patch for 1.4.0

[Marius Vollmer <mvo at zagadka dot ping dot de>]

guile-user@thewrittenword.com writes:

> On Sun, Sep 10, 2000 at 04:23:28PM +0200, Marius Vollmer wrote:
> > Albert Chin-A-Young <china@thewrittenword.com> writes:
> > 
> > > Addes --with-readline=DIR option to specify readline include/library
> > > in an alternate directory.
> > 
> > I don't think we should add this option.  In my opinion, the system
> > should be set up in such a way that readline and all other needed
> > libraries are automatically found.  This is much easier in the long
> > run.
> 
> So you advocate people doing:
>   $ CPPFLAGS="-I[path to readline include]" \
>   LDFLAGS="-L[path to readline lib]" ./configure [blah]

No, not really.  They should install packages either in standard
locations like/usr/local or set up additional `standard' locations by
defining LD_LIBRARY_PATH, C_INCLUDE_PATH and whetever else is needed
on their system.

> It is not uncomment for programs to specify an autoconf option to
> specify the location of a program. Consider Glib and Gtk.

Yes, I don't terribly like this either, any more.  The basic problem
is that you can't say to the compiler "take -lgtk from /opt/gtk/lib",
all you can say is "look also in /opt/gtk/lib".  When nothing else is
there, that's fine, but I frequently have problems on systems where I
use Gtk together with Guile.  Here is a description of the problem
that I wrote in some other context:

# The Problem
# -----------
# 
# For the sake of discussing the utility of this hack, consider three
# packages: ME, FOO and BAR.  ME wants to use both FOO and BAR and
# expects FOO and BAR to be already installed in the system when ME is
# to be configured and build.  Further, both FOO and BAR come with
# little programs, foo-config and bar-config, that provide
# configuration information to other packages.
# 
# Now imagine we have this situation: both the FOO and BAR package
# come with the OS and have been installed in /usr.  But the user has
# also installed its own (newer) version of BAR in /home/fred.  He
# wants ME to build with this newer version, of course.
# 
# The configure script of ME uses foo-config and bar-config to find
# out how to link to libfoo (from FOO) and libbar (from BAR) and it
# correctly finds:
#
#   foo-config says to use:   -L/usr/lib -lfoo
#   bar-config says:          -L/home/fred/lib -lbar
#
# The ME package dutifully invokes the linker thus:
#
#   cc -o me me.o -L/usr/lib -lfoo -L/home/fred/lib -lbar
# 
# The problem with this is that the linker will pick up
# /usr/lib/libbar instead of /home/fred/lib/libbar because /usr/lib is
# first on the search path.
# 
# The only one who has enough information to get out of this dilemma
# is Fred himself, because he has configured his system and knows what
# prefixes he wants to use.
# 
# Thus, we need a way for Fred to tell the ME package that he wants
# the linker to invoked in this fashion
# 
#   cc -o me me.o -L/home/fred/lib -L/usr/lib -lfoo -lbar
# 
# because he knows that he wants the /home/fred prefix to shadow the
# /usr prefix.  (On the other hand, only ME knows that it wants to
# have -lfoo precede -lbar.)

The best solution to this problems appear to me to be to encourage the
user to set up his system so that configuration and compilation of a
package can succeed without any additional -L and -I options.  The
previuous text is from a shell script that tries to implement another
solution, but I would have to merge it with libtool for it really be
of any use (I think).

If you would ask me directly, I'd say that the Unix library model is
broken and needs to be fixed.  `--with-readline' does help, but I
think other solutions are preferable.

> > >  dnl Should we check for curses, terminfo, and termlib, too?
> > > -for termlib in ncurses termcap ; do
> > > -   AC_CHECK_LIB(${termlib}, tgoto, 
> > > -                [LIBS="-l${termlib} $LIBS"; break])
> > > +for termlib in ncurses curses termcap terminfo termlib; do
> > > +   AC_CHECK_LIB(${termlib}, tputs, [LIBS="$LIBS -l${termlib}"; break])
> > >  done
> > 
> > You add "curses", "terminfo", and "termlib" here.  What is the
> > motivation for this?  I.e., on what systems do you need this?
> 
> On Solaris at least, readline needs the terminal libraries. The above
> is stolen from Octave and has been incorporated into many programs using
> the readline library (e.g. gnuplot, lftp, librep, sawfish, bc, ddd,
> libxml, fvwm).

Ok, I'll install this.  Thanks!

> > > -if test $ac_cv_lib_readline_main = yes \
> > > -        -a $ac_cv_var_rl_getc_function = no; then
> > > +if test "$ac_cv_lib_readline_readline" = yes \
> > > +        -a "$ac_cv_var_rl_getc_function" = no; then
> > 
> > What are the quotes needed for?
> 
> The following:
>   AC_CHECK_LIB(readline,main)
> does not *properly* determine whether or not you need the readline
> library. What you should do is check for a function in the library to
> test whether or not you need to link the library.

I'll use

    AC_CHECK_LIB(readline,readline)

instead.

(But what are the quotes needed for? ;)
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user