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

[Alexander Neundorf]

On Tuesday 29 November 2011, Alexander Neundorf wrote:
> On Friday 18 November 2011, Patrick Spendrin wrote:
> > Am 18.11.2011 02:02, schrieb Alan W. Irwin:
> > > Alex, is it possible your KDE Windows developers who are objecting to
> > > pkg-config tried a version from years ago when it did not have all
> > > these Windows issues sorted out? I suggest you tell them to
> > > investigate again using modern pkg-config.  For example, they could
> > > follow the experiment I tried using the all-in-one GTK+ 2.22.1 bundle
> > > you can download from http://www.gtk.org/download/win32.php.  If that
> > > works (which it should do if the bundle is properly installed) or if
> > > they use a modern binary version of pkg-config for Windows from that
> > > same location, ask them to attempt to find any Windows binary package
> > > that is broken with regard to pkg-config. There might be some of
> > > those.  But I very much doubt that is a systematic problem since it is
> > > so straightforward (install the *.pc files in the correct relative
> > > location in the install tree) to deal with the pkg-config Windows
> > > issue the KDE Windows developers have been so concerned about.
> > 
> > First I want to explain our setup again a bit more:
> > KDE on Windows is built using two compilers, gcc from the mingw-w64
> > project (both 32bit and 64bit) and the no-charge Microsoft compiler
> > (Visual Studio Express Edition). Since there are problems with the
> > compatibility of C++ libraries and for easier debugging, we build all
> > depend packages ourselves with each compiler (so there are multiple
> > packages even for C libraries). For that, we sometimes add heavy patches
> > to those libraries (adaptions to the regular Unix layout for all
> > compilers even for msvc built libraries e.g.). These patches normally
> > don't add a missing .pc file.
> 
> If there is no .pc file, then pkg-config doesn't return anything, and the
> find_library() etc. calls simply search as they always do, without the
> hints from pkg-config.
> That's fine, since the find-modules must also work properly at least for
> standard installs if pkg-config is not installed at all.
> 
> > One of the other problems still persists - pkg-config is not needed for
> > those packages now (think of standard build libz which also installs a
> > .pc file). So for us the question is of course whether there is a real
> > need to add an additional thing to the build system.
> 
> I agree to that. The find-modules should, at least for normal installs,
> also work without pkg-config.
> But they also should not fail if pkg-config is there and returns something
> for a normal install.
> If there are such failures, we need to do something about them.
> 
> > I will try to check with newer builds of pkg-config this weekend though.
> 
> Did you have time to do that ?
> How did it work out ?

So it seems the conclusion is that Find-modules which have code like this:

IF(NOT WIN32)
  FIND_PACKAGE(PkgConfig)
  PKG_CHECK_MODULES(PC_LIBXINE QUIET libxine)
  SET(XINE_DEFINITIONS ${PC_XINE_CFLAGS_OTHER})
ENDIF(NOT WIN32)

can be changed to simply:

FIND_PACKAGE(PkgConfig)
PKG_CHECK_MODULES(PC_LIBXINE QUIET libxine)
SET(XINE_DEFINITIONS ${PC_XINE_CFLAGS_OTHER})

Right ?

Alex