Hi,

At Fri, 25 Jul 2003 07:11:32 +0900,
Brian Candler wrote:
> > > Ah, there it is. But this now seems inconsistent. If you're going to put the
> > > library in /usr/local/lib, surely ruby.h should be installed in
> > > /usr/local/include?
> > 
> > Maybe, /usr/local/include/ruby-1.8?  Or, as you mentioned,
> > multiple versions won't be possible to coexist.
> 
> But same applies to /usr/local/lib/libruby-static.a

A difference is, header name is not easily changeable, but
library is.  The formar is coded in many sources whereas the
latter is decided by configuration and supplied by a file,
rbconfig.rb.  So what we can do about headers is moving
directory and providing there by -I option.

Some other projects install their headers under particular (and
even version specific) directories, freetype, glib, gdk, gtk,
gnome family, php, python, wine and so on.

> I'm sure this has been discussed before at length before the decision was
> made to change it. But to me it seems to be consistent then both the library
> and headers should be in the same system-expected place: either
> 
> (1)
> /usr/local/lib/libruby[-static].a
> /usr/local/include/ruby.h
> 
> OR
> 
> (2)
> /usr/local/lib/ruby/1.8/i386-freebsd-4.7/ruby.h
>                                          libruby[-static].a
> (as it was for 1.6.8)
> OR
> 
> (3) like (2), but with symlinks from the first place to the second.

I prefer (1) with modified as above.  A problem about (3) would
be there are platforms don't have symlinks.

> Also, why "libruby-static.a" instead of "libruby.a" ? I don't know of
> anything else that uses a different name for the .a and the .so.

For the case of linking ruby statically, by -lruby-static.  For
instance, try_link and try_run mkmf.rb need to run linked
programs, so if they are linked dynamically, they cannot be run
unless libruby.so get installed.

-- 
Nobu Nakada