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]

Re: Announce: guile-dblib-0.9 available (beta software)


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.