bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: --enable-pc-files and nonexistent $PKG_CONFIG_LIBDIR


From: Thomas Dickey
Subject: Re: --enable-pc-files and nonexistent $PKG_CONFIG_LIBDIR
Date: Sat, 04 Aug 2012 09:49:41 -0400
User-agent: Mutt/1.5.18 (2008-05-17)

On Sat, Aug 04, 2012 at 12:47:47PM +0200, Sven Joachim wrote:
> Hi,
> 
> This has disturbed me, and apparently other people as well[1,2], for
> quite some time: if the --enable-pc-files option is given (and,
> optionally, --with-pkg-config-libdir), but the directory where the .pc
> files are to be installed does not exist, pkg-config support gets
> disabled.
> 
> What are the reasons that the CF_ENABLE_PC_FILES macro disables
> pkg-config support if $PKG_CONFIG_LIBDIR does not exist?  I can imagine
> that there will be a problem if it exists and is a non-directory, but if
> it's not there, "make install" should just create it.

Essentially what that's saying is that the configure script should
install package files somewhere.  I say "somewhere", because there's
no apparent way to ask the pkgconfig program where they should be.
Compounding this, there are different places (according to different
systems).  Looking at my logs, I see these:

        /usr/lib/pkgconfig
        /usr/local/lib/pkgconfig
        /usr/mpkg/lib/pkgconfig
        /usr/pkg/lib/pkgconfig
        /usr/share/pkgconfig

I seem to recall that multiarch stuff can add cases - some of the recent
changes have been done to address concerns about cross-compilers, which
add _still_ more cases.

In any case, the pkgconfig directory should be owned by the pkgconfig
program - which makes it pre-existing from my point of view.

The followup comment about $DESTDIR is moot, because it is not part
of the configure-script's check.

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]