C header file location

[Marvin Humphrey <ma...@rectangular.com>]

On Thu, Mar 18, 2010 at 09:54:18PM -0500, Peter Karman wrote:
> > The easy way to handle things would be the same way we're going with
> > ProximityScorer, glomming onto the KinoSearch build directly.  But we could
> > also try jamming stuff into /usr/local/include and worry about permissions
> > issues and portability later.
> 
> maybe parse 'ccflags' from $Config ? that seems to include the -I paths for the
> perl binary itself, which might be more install-specific than assuming
> /usr/local/include.

Prior to the adoption of our new backwards compatibility policy, I would have
thought it necessary to install headers into different locations for each
host.  So if you had KS/Lucy installed with Perl 5.8.9, Perl 5.10.1, and Ruby
1.9.1, that would mean 3 different include directories with separate copies of
our header files.

Now, though, I think /usr/local/include or its closest equivalent is the right
place.  The unstable branch is only meant to be used on machines where the
user has control over what gets installed; it simply won't be safe to have
multiple hosts with out-of-sync versions and users will have to make sure they
"don't do that".  And stable forks like KinoSearch3 will have stable C APIs:
so long as we don't accidentally force-downgrade by overwriting KinoSearch3
version 3.01 with version 3.00, it will be safe to install them into a shared
location.

Hmm, as a matter of fact, I think it now makes sense to install our compiled
shared objects into /usr/local/lib, like e.g. Swish does.

Marvin Humphrey