Re: Dropping indirect dependencies from libgnutls-config --libs
- To: email@example.com
- Subject: Re: Dropping indirect dependencies from libgnutls-config --libs
- From: "Martijn van Oosterhout" <firstname.lastname@example.org>
- Date: Sat, 1 Jul 2006 16:37:05 +0200
- Message-id: <[🔎] email@example.com>
- In-reply-to: <20060701032519.GB6804@grimlock.home>
- References: <20060629173856.GA3733@downhill.aus.cc> <20060629183222.GA20370@glandium.org> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20060701032519.GB6804@grimlock.home>
On 7/1/06, Vincent Ho <firstname.lastname@example.org> wrote:
On Fri, Jun 30, 2006 at 03:42:12PM +0200, Martijn van Oosterhout wrote:
> It is also used to compile contrib modules that are included in the
> distribution. If you started using pkg-config you'd have introduced a
> build dependancy on a GPL'd program in a BSD licenced package, not
> exactly a good idea.
Hmm, that's an interesting thought, but I'm not sure it's a strong
concern. Stephen Gran already mentioned libtool, but regardless you can
arrange things so pkg-config isn't a strict dependency. Most configure
scripts support various --with-foo arguments, so people who don't wish
to use pkg-config can simply pass --with-foo=$HOME/local/foo.
pkg-config would thus be helpful but not a strict build dependency.
There's two seperate issues here. Firstly, using pkg-config to find
libraries. Autoconf solves this nicely already. Maybe in the future
autoconf can use pkg-config, but pkg-config is not widespread enough
to really do that yet. No dependancy here.
Secondly, providing a .pc file so other people can find you. For the
libpq client library this might be useful. This doesn't require
pkg-config at all, you just need to install a file of the right format
in the right place. So no dependancy here either.
However, the bit of the thread I responded to was about deprecating
pg_config in postgres in favour of pkg-config. pg_config doesn't exist
to find the libs or header files for libpq (for client programs), it's
existance to provide the necessary information to build shared objects
to load into the server. It provides similar information to "perl -V"
and I don't think anyone is going to suggest loading all that into
The dependancy I'm talking about would come about because of contrib
modules shipped with postgres that create server modules and thus use
pg_config to get the correct compiler flags. Replacing that with
pkg-config creates a build time dependancy on pkg-config, which is
Let me rephrase my previous comment: pkg-config is good for library
packages to help other programs find them. It's not as useful for
building libraries to load into a specific program.
Have a nice day,
Martijn van Oosterhout <email@example.com> http://svana.org/kleptog/