Re: guile-config and other packages compiling against guile

[Greg Troxel]

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 <address@hidden>