I am used to pkgsrc (NetBSD) pkg management, which generally doesn't
have a split between "run this" and "link with this files", so I may
be missing some experience.
I believe that if "guile-config [link|compile]" runs, then the libs
should be there. A simple solution is to ask packagers to put
guile-config in the same package as the headers if guile is split into
multiple packages.
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.
I can see this point. But, configure scripts may well expect that
either
guile-config is not found
or
'guile-config link' runs and one can link.
The autoconf macro we distribute should of course play well with
however guile-config ends up.
Another thought is to push guile-config link and compile into
pkgconfig, where the .pc would be in the headers package. Then
guile-config could exec pkg-config guile --libs as compatibility, and
this would/could lose if the headers+.pc aren't there.
test -f $(guile-config info pkgincludedir)/gh.h
I see your point, but this feels kludgy and not how other programs
behave, or at least not how I think they behave.
How does glib (1) handle this? There is glib-config. I can't tell,
because on NetBSD I simply get all of glib, so either it works or it's
all not present, including glib-config. So I really mean how does
Debian handle glib-config in glib1?
One can also argue that guile-config info is really useful for
developer types, and that no 'user' would want to see it, and thus
simply put guile-config with the headers.
[Note that I've avoided saying "the development package" because this
notion is not universal. In pkgsrc, foo-devel is usually an unstable
version of foo, not a run/compile split of foo.]
--
Greg Troxel <[EMAIL PROTECTED]>
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
