pkg-config files not installed when using MinGW

Issue #1135 new
Marvin Gülker
created an issue

Hi,

the build system does not install the pkg-config files when MinGW (with MSYS natively or as a crosscompiler from a Unix system) is in use as the compiler toolchain. This is because in CMakeLists.txt all .pc files are subject to this condition:

if (UNIX AND NOT APPLE)

UNIX is not set when targetting Windows, regardless of whether it's MinGW or VisualStudio.

You should probably not make the assumption pkg-config is only in use when compiling for Unix systems. Instead, a new flag CEGUI_BUILD_PKGCONFIG or similar would be nice. You can still have this flag default to OFF on non-unix systems.

Also be ensure that the pkg-config file includes CEGUI_STATIC as a required flag when CEGUI is compiled statically.

  • Reproducibility: Always
  • Operating system: Gentoo Linux 64-bits
  • Reproduction steps: See #1131

Greetings Marvin

Comments (17)

  1. Tony Theodore

    Requiring the latest CMake is ideal, we build it as part of MXE so all users are on the same version. I've just kicked off a full build to test the 3.5.2 --> 3.6.1 update - these are seamless these days (takes about 16 hours to confirm).

    I've also switched to tracking the v0-8 branch so changes can be tested quickly (I'll try to push it soon).

  2. Yaron Cohen-Tal

    @Marvin Gülker, @Tony Theodore: Ok, my current solution is bad for various reasons, including changing current default behavior. I've pushed a new solution, which is compatible with the original behavior. Now, pkg-config files r installed as a separate component called cegui_pkgconfig. By default, it's still installed only when targetting "UNIX AND NOT APPLE", as it was originally. However, with cmake >= 3.6, u can install it manually by running cmake -DCOMPONENT=cegui_pkgconfig -P cmake_install.cmake from the build directory.

  3. Tony Theodore

    Unfortunately, the cmake update breaks a few packages (never say seamless!) so we can't update to it immediately.

    The component-based install seems like creating extra work for users when a declarative option like -DCEGUI_BUILD_PKGCONFIG or autodetection is both easier to implement and doesn't require new cmake features:

    if ((UNIX AND NOT APPLE) OR CEGUI_BUILD_PKGCONFIG)
    # or
    if ((UNIX AND NOT APPLE) OR MINGW)
    

    The build script for the manual install would also have detect which system it's running on to avoid installing twice - there's no harm in that but it seems unnecessary.

  4. Yaron Cohen-Tal

    @Tony Theodore: Lol we'll eventually get it right :)

    Ok I've created a new advanced cmake option CEGUI_INSTALL_PKGCONFIG that controls whether pkg-config files r installed. It's default value is still UNIX AND NOT APPLE. I've pushed the new version.

    I'm afraid we can't change the default in an ABI/API compatible branch, but we'll change it to CMAKE_HOST_UNIX AND NOT CMAKE_HOST_APPLE ) in the API incompatible branch. I think MINGW has nothing to do with it - u might just as well use MinGW from a non-unix environment (e.g. MinGW-builds) where the current default (off) seems right to me.

  5. Tony Theodore

    Great, thanks! The *.pc files are now installed and thanks for clarifying the defaults.

    Next up is using these for static linking. The files themselves don't have the *_Static suffix for libs, the -DCEGUI_STATIC flag, or other Requires.private: freeimage xerces-c freetype2 libpcre ... Requires: CEGUI-0 = 0.8.7 glut gl glew. For MXE builds, we can do post-install processing on these but it would be ideal to have the files generated with the detected CMake options.

    Probably the main question is handling -DCEGUI_STATIC. We use pkgconf, an alternate implementation of pkg-config that has a Cflags.private section. This allows easily using the same *.pc.in files but doesn't help with the lib suffixes.

  6. Yaron Cohen-Tal

    @Tony Theodore: NP, thanx to u and @Marvin Gülker too for reporting the problems, it helps us improve cegui.

    I'll try to look into those issues, however currently I improve the static building support in general and there's some work to do there. I expect that work to take more than a few days. I'll let u know when there's something worth testing.

  7. Tony Theodore

    @Yaron Cohen-Tal , thanks, I wasn't sure about the watching toggle.

    Cross-building is generally easier than native building (for me), but windows needs name mangling for symbols (via CFLAGS) and libraries (since msvc *.lib files can be either static or shared). I was just ruminating after a long day;)

  8. Log in to comment