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?)
Cheers,
Peter