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
