[Top][All Lists]

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

Re: [Chicken-users] chicken-setup

From: Peter Bex
Subject: Re: [Chicken-users] chicken-setup
Date: Wed, 16 Jul 2008 09:02:23 +0200
User-agent: Mutt/

On Tue, Jul 15, 2008 at 12:48:56PM -0700, Shawn Rutledge wrote:
> On Tue, Jul 15, 2008 at 12:11 AM, Peter Bex <address@hidden> wrote:
> > I don't think this can be solved automatically (unless we want to
> > recreate Autotools or CMake) so what is needed is a way to override or
> > add to existing search paths by passing switches to chicken-setup,
> > which it then can pass on to the compiler. Example:
> >
> > chicken-setup foo.egg -I /opt/foo/include -L /opt/foo/lib
> That could be a last-ditch way to solve problems but I would hope most
> users wouldn't need to do that for most eggs.
> Is there anything wrong with putting extra -I's and -L's in the meta
> file, with some possible guesses the egg developer can think of, where
> a particular library or include might be located?  And chicken-setup
> could append the usual suspects automatically, like /usr/include,
> /usr/local/include etc.

That simply won't do.  Here's why:

On OS X, you have Fink and Darwinports.  Fink installs to /sw and
darwinports to /opt/local.  On NetBSD and many other systems you
have pkgsrc, which installs to /usr/pkg.  On FreeBSD you have ports,
which installs to /usr/local by default, but on systems where people
don't have root access they'll install somewhere under their homedirs,
in which case all bets are off regarding the location.  I have no idea
how stuff works on native Windows, but you can bet there's very little
standardization there.

And then we haven't even touched on all the freaky places some Linux
distros put things.  (or /lib /lib64 differences for amd64)

It's a reasonable assumption, however, to include Chicken's PREFIX in
the search paths, since if people install Chicken using their package
manager, very often it will get the same PREFIX as other packages that
chicken eggs might want to wrap.

As Min Thu suggested, using pkgconfig for programs which have that
is a good idea, since that will ~always work properly. (perhaps provide
a switch to disable usage of pkgconfig in case it isn't installed?)

"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

Attachment: pgpBeWO_wgbxM.pgp
Description: PGP signature

reply via email to

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