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: Sven Joachim
Subject: Re: --enable-pc-files and nonexistent $PKG_CONFIG_LIBDIR
Date: Sat, 04 Aug 2012 16:31:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

On 2012-08-04 15:49 +0200, Thomas Dickey wrote:

> 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.

Right, same as with --prefix, --libdir, --bindir etc. which might also
be non-existent at build time.

> 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

Those are standard places (at least the first, second and fifth).

> 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.

Correct, that's why it is important that the installation directory for
the .pc files is user-specifiable (--with-pkg-config-libdir).

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

That does not match reality, since pkg-config cannot really ship a
directory for each possible architecture that you may want to
(cross-)build for.  In Debian, dpkg-architecture knows currently about
284 of them.

Cheers,
       Sven



reply via email to

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