[CMake] [RFC] How to use pkg-config under Windows (... and OSX)?

[David Cole]

On Thu, Nov 17, 2011 at 2:06 PM, Alexander Neundorf
<a.neundorf-work at gmx.net> wrote:
> On Thursday 17 November 2011, David Cole wrote:
> ...
>> If a project does something like this (distributes a file with
>> build/install time information in it) but then lets the end user of
>> the binary installation put it wherever they please...... then the
>
> that's what I hear from our Windows developers.
>
>> distributed files should not contain any build/install time
>> information in them,
>
> But according to what I hard this is what is done...
>
>> but rather should parse and use their actual end
>> user install location if they need to provide that information on an
>> end user's system.
>
> ...instead of this.
> I also don't know whether pkgconfig supports something like $ORIGIN to
> reference its own location in pc-files, which might help.
>
>> It sounds to me like pkg-config is simply not suitable for use with
>> packages that may be installed/copied anywhere.
>
> Same here.
>
>> What is the problem we are trying to solve?
>
> From my very private POV:
> I'm reviewing the Find-modules we have in KDE.
> Many of them do
>
> if(NOT WIN32)
>   pkgconfig stuff...
> endif()
>
> Now, I do not know from personal experience whether this if() make sense or
> not.
>
> If it does make sense, then it might make sense for any package. In that case,
> it would also make sense to have a global solution for this (like an option
> CMAKE_SKIP_PKGCONFIG_ON_WIN32), instead of having to put this if() in each and
> every Find-module.
>
> If the if() doesn't make sense, then it can be simply removed, and pkgconfig
> is used everywhere. But our Windows developers said they don't want that.
>
> OTOH, since the Find-module must also work without pkgconfig (since we cannot
> rely on that it exists everywhere), one could also argue that pkgconfig is
> unnecessary completely in Find-modules, but then another group of people
> starts complaining that we are ignoring existing standards and they really
> want to use pkgconfig.
>
> So, what I'd like to get, is first some more opinions and experiences with
> this, and as result some reasonable guidelines how to use pkgconfig properly
> (or not).
>
> Alex
>

I think we should completely ignore pkg-config on the grounds that
their packages are not re-locatable, yet there are some packages that
allow relocation anyhow. It should simply be made clear to everyone
that pkg-config packages must not be, cannot be relocated.

Or, if we are wrong in this conclusion, somebody who cares about
pkg-config as an "existing standard" should step forward and defend
the inexplicable practice of relocating non-relocatable packages and
then informing queriers of the old location...

But..... if you insist on supporting pkg-config to appease those who
would use it anyway despite this limitation, then I would vote for
something like this:

if(NOT DEFINED CMAKE_USE_PKGCONFIG)
  # Default to using it:
  set(CMAKE_USE_PKGCONFIG 1)
  # But not on Mac or Windows, where end-user relocation is common practice:
  if(APPLE OR WIN32)
    set(CMAKE_USE_PKGCONFIG 0)
  endif()
endif()

if(CMAKE_USE_PKGCONFIG)
  pkgconfig stuff...
endif()


up to 4 cents now,
David