A bug reported against the Debian packages raises an interesting
question. Should the fact that guile-config provides an answer
(i.e. exists and produces a result) for something like "guile-config
libs" be the correct indicator that it is safe to try to compile and
link against guile?
This came up because as it stands now, guile-config is in the
guile-1.6 package which includes the guile binary and libs, but does
not contain the development symlinks (.so links) or the header files.
The latter are in the guile-1.6-dev package. So if you have guile-1.6
installed, you will have a functional guile and guile-config, but you
won't be able to compile and link against guile.
I do this because it seemed like "guile-config info" provides
information that may be useful even if you're not interested in
compiling anything against guile.
So the question is do we want people to be able to use guile-config
(i.e. for info) even if the headers and .so links aren't installed,
and if so, then what do we want to recommend as the true indicator
that it's safe to try and compile and link against guile?
One option (for future versions) would be to have "guile-config
{libs,compile}" just fail if the libs aren't installed. Another might
be to require configure.ac scripts to test something else, perhaps
test -f $(guile-config info pkgincludedir)/gh.h
or whatever.
Of course, now that I look at the output of "guile-config info", some
of it seems a bit questionable. For example, it mentions build tree
directories which often won't be relevant after an install, and
although it mentions $(pkgincludedir), most of our headers don't
actually go there. They go to $(includedir)/libguile/.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
