[Top][All Lists]

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

[Gcl-devel] Re: gcl compilation report (redhat 7.3, gcc 3.2, gcl 2.4.3)

From: Dan Hitt
Subject: [Gcl-devel] Re: gcl compilation report (redhat 7.3, gcc 3.2, gcl 2.4.3)
Date: Mon, 11 Nov 2002 04:34:38 -0500 (EST)

Hi Camm,

Thanks for your mail, and addressing all the points i earlier sent you.

This is just to clarify what i meant, and is not intended as
any sort of complaint.  You've done a good work, and these are
second order points.

> > (2) configure must be done in the source directory (as opposed to
> >     a separate build directory)
> > 
> I don't understand this.

Suppose that i've unpacked the distribution and it is in
Then i do this:
    mkdir /home/lisp/build
    cd /home/lisp/build
    ../gcl-2.4.3/configure   <<<configure arguments . . .>>>
The configure script will work, or, at least, write some files and then
exit with 0 status.

But when i type
in the /home/lisp/build directory, the build will fail.

However, if i instead do
    cd /home/lisp/gcl-2.4.3
    ./configure <<<configure arguments . . .>>>
the build will work.

That's what i mean by configure only works in the source directory.

It is very useful to be able to configure in a separate directory from
the source directory so that one can maintain multiple built versions
in different directories (e.g., built with different compilers,
different configure options, or even for different architectures).
For example, gcc can be and is recommended to be built this way, and
other programs also.  And i would think that maintainers would like
this also, so that they also could more easily test how different
configure options, compilers, etc treat exactly the same code.

> > (3) The --prefix option to configure indeed makes the binaries and
> >     lib go to the right place, but the info and emacs files do
> >     not follow.  I hand-edited makedefs and makedefc to force
> >     the info to go in a subdirectory of the prefix directory.
> Can you provide some specifics as to where configure decided to place
> these on your box, and where you would like them to go?  Also what
> machine you are using?  The Linux file system standard specifies that
> non-machine code like these files must be located separately from the
> binaries, so that /usr/share can be NFS mounted.

First, i think that you're doing the right thing by trying to follow
the Linux file system standard, and i think the default behavior that
you have chosen makes the most sense.

My problem is a customization one, and is of course not as important
as selecting the best defaults, which you have done.

My problem is that i do not know how to force, through the configure
script, the info and emacs files to go where i want them.  Instead, i
had to hand-edit some makefile-associated files to make the info go
where i want it to.  For my setup, i do not want to install anything
as root.  So, instead, i create a user account `lisp', and do the
installs of gcl-2.4.3 in this account, and adjust the PATH and
INFOPATH variables of other accounts to point to

This way i can maintain multiple different versions of gcl, which
presumably have different info files attached. 

So, for my particular usage, it would be convenient to be able to
override the default locations by supplying appropriate arguments to

Thanks again for your work on gcl 2.4.3, and although i think
that gcl could be improved by tuning the configure a little more
to better enable multiple lisp installations, i really appreciate
the work you have done.  It is really a service for anybody who
wants to use lisp.


reply via email to

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