Re: [Pan-users] Pan 0.133 refuses to work any longer

[Mike Brown]

On Sat, Aug 25, 2012 at 03:26:33PM +0200, Rhialto wrote:
> I think that the vast majority of software that uses configure scripts
> also uses pkgconfig,  these days.

IMHO, I think that the use of pkg-config is unfortunate.

> As I understand it, pkgconfig is used to determine *where* something is
> on the system. This rather varies a lot over systems - even between
> various Linux distributions, I believe. Not to mention other Unix
> systems; I use NetBSD where packages are installed (by default) under
> /usr/pkg, but I expect that you can change that and that configure +
> pkgconfig should cope with that.

The config files tha pkg-config are looking for are in the expected location,
but not all RPM packages update/create the file that pkg-config is looking
for.  In the case of pan, the info for GMIME doesn't exist, even though
GMIME is installed on the system.  As a result, configure gives up instead
of looking at the default install location for libraries, etc., or even using
rpm tools to determine if it is installed and where.

If all of the packages that get installed created the cofig files that
pkg-config is looking for, then I wouldn't have an issue.  But, not all do,
so to solely depend on it, IMHO, is shortsighted.

> Pkgconfig also supplies the compilation and link options that are
> necessary to use some library.  It would be impossible to put all
> thinkable combinations of that in a configure script in an attempt to
> find out which options to use.

So, how did we get away with not using it over the decade, or so, before
pkg-config came about?  Seemed not to be an issue before pkg-config, so
why now?

> The alternative is "the old-fashioned way" where you supply configure
> with tons of options like "--with-foo-library=/usr/lib/foo
> --with-foo-includes=/usr/include/foolib".

That would mean my looking for that info.  I would be doing the same thing
that configure could also do, and that is look in the standard install
locations.  Then, if the package can't be found, error out.  Frankly, I
shouldn't have to configure configure.

> Not that there is nothing wrong with pkgconfig. My favourite peeve for
> instance is that often, if a shared library uses some other shared
> library, that dependency is made explicit even when it need not be. That
> results in unnecessary update dependencies: when you're updating some
> lower level library, you are forced to update more than just those
> libraries/programs that actually use it directly.

While it might be an annoyance, at least configure will finally finish so that
the actual compile can take place.

Not in this situation.

MB
-- 
e-mail: address@hidden | address@hidden            /~\ The ASCII
        address@hidden (140 char limit)       \ / Ribbon Campaign
Visit - URL: http://vidiot.com/                           X  Against
             http://vidiot.net/                          / \ HTML Email