This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Jim Blandy <jimb@red-bean.com> writes: > > I've added support for two to non-inuitive configure features. The > > first of these is called 'dblib', and you can use it to specify where > > your dblib installation is at. The second of these is called simply > > 'guile', and it is used similarly, to specify where you have guile > > installed. If you've got guile installed in /usr/local, and > > /usr/local is in your path, then you shouldn't need this to build. > > > > To build in my installation, I configured like this: > > > > ./configure --enable-guile=/opt/guile --enable-dblib=/opt/sybase > > Maybe I'm misunderstanding, but: No, you're not. I'm probably trying to solve a non-problem. > When I run dblib's configure script, does --enable-dblib=PATH tell > dblib where to install itself? If so, why don't you use --prefix=PATH > instead? I was trying to give the user an easy way to tell the configure script where to find the sybase headers and libraries. I guess the normal way is to do stuff like this, which I found somewhat tedious and distasteful: export CPPFLAGS="/opt/sybase/include:${CPPFLAGS}" export LDFLAGS="/opt/sybase/lib:${LDFLAGS}" ./configure You see, everthing inside Goldman has got it's own /opt directory, so it's impractical to have LDFLAGS and CPPFLAGS constantly set to the union of every software package you ever might want to use. So I was trying to give the user a way to do this without having to do the environment variable stuff. Maybe this is silly, or maybe there is an easy way to do this, and I don't understand autoconf. (I'm not ashamed to say that I don't understand the whole automake / autoconf / libtool suite. My head nearly exploded the other night when I tried to learn them, and I still haven't tried to integrate automake). > I think you don't need --enable-guile=PATH either. The configure.in > file should use the GUILE_FLAGS macro, in guile-core/guile.m4; that > is meant give you the CFLAGS and LDFLAGS you need to link against > Guile. It works by running the guile-config program, which must be > in your path. Thanks. This I eventually found in the guile NEWS file, but after I posted. I'm planning to switch over to GUILE_CFLAGS etc. One question: a lot of times I've got guile-1.3 installed in /opt/guile, and I've got some snapshot installed in /home/mcmanr/local. How does one specify that configure should use the guile in /home/mcmanr/local? I guess I should just read guile.m4 and answer my own question. > The thing is, your package is not unusual; if you need weird, > nonintuitive configure options, everyone else writing a Guile > package will too. So this is very much something for us to work on > until it goes smoothly. I'm interested in changing Guile as > necessary to make this possible. I hope I was clear about what I was trying to achieve. Suggestions welcome. -russ -- "Even if you are on the right track, you'll get run over if you just sit there." --Will Rogers (1879-1935)