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: > > 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. > > I agree, it's clumsy. > > So, dblib is the name of your package, right? And your package's > configuration script needs to be told (because it has no way of > guessing) where sybase is installed. > > For starters, the configure script should guess the most common places > that the Sybase files are installed. It should just check for the > presence of some distinctive header in a list of common directories. > > Then, you should use a --with-sybase=PATH option; those are > designed specifically for cases like this. Look in the autoconf > documentation for AC_ARG_WITH (look in the index under ARG_WITH). Cool, thanks. I've changed to using --with-sybase. There aren't many examples of this stuff to look at to learn the idioms, because most packages are not distributed with maintainer-specific files and tools. So one can't casually learn about this stuff by sniffing through distributed software, which makes learning these things a bit more challenging. An integrated Guile solution would well serve the software configuration problem domain. The current mish-mash of m4, perl, and Bourne shell is truly frightening. I guess the problem is that the intersection of the set of people who know Guile and the set of people who know the GNU maintainer tools is a very small number of people. > > (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). > > If you just consider autoconf by itself, that's a good start. It's > not so bad. I started with this, and I agree it's not too bad. > libtool is pretty independent of both of them. Read the libtool > manual, and you'll be okay. I actually got this working, too, without that much hassle. > Automake makes my head explode too. Which seems like a bad thing to > me. I'm still wrestling with this alligator. I'm going to try to put out a new version of the library that uses automake, that has --with-sybase, and that uses GUILE_FLAGS. I'm nearly there, actually. > > 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. > > I don't think there's currently a graceful answer to that. You just > need to make sure guile.m4 finds the `guile-config' script in > /home/mcmanr/local. Perhaps GTK (on which Guile's facility is > modeled) has a better solution. Maybe '--with-guile=/home/mcmanr/local' would work? It's kind of counter intuitive, though, because it implies that guile is optional, but of course it isn't really, so maybe this is a bad idea. -russ -- The novice doesn't know the rules, and creates monstrosities. The practitioner follows the rules, and creates good works. The master understands when to break the rules, and creates wonders.