> Usually, I put libraries and include files in /usr/local/lib and
> /usr/local/include, and my system has no trouble finding them.
Most of the systems that I run across with ILU don't do that, primarily
because the people unpacking and experimenting with these systems want
to try them out elsewhere first. So someone might install Guile under
/tmp or ~username, for instance, then try compiling ILU to work with it,
also in some non-standard location. Larger installations that support
many machines also typically don't use the /usr/local/ paradigm, instead
installing on some file server which is mounted under some name such as
/net/foobar/package/ILU/. I find that most people, however, seem to be
able to cope with the idea of having an executable on their PATH, if
things are to work right.
> On one machine where I am not root, I put things in ~nemo/lib and
> ~nemo/include. And I have CFLAGS set in my config.site so that
> those directories are searched.
Again, many if not most of the systems we are installing on won't have
any notion of a config.site file.
> It is possible, at least in theory, that someday someone might want
> to link against Guile without having the standalone execuatable binary.
Indeed, this possibility does bother me. I'd prefer to have every GNU
package contain an executable script which would always be installed, so
that autoconf could search for this, instead of for some executable that
may or may not be installed. For guile, for instance, this would be
called "guile-installation-info", and it would write to standard output
the PREFIX and EXEC_PREFIX values that Guile was installed with.
> Your proposed solution also will break cross-compiling. Cross-compiling
> often doesn't quite work right with GNU tools anyway, but given two otherwise
> equal solutions, you ought to use the one that works for cross-compiling.
Of course. What's the second equal solution I should consider?
Bill