New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefer pkg-config over freetype-config if possible #1185

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
5 participants
@Polynomial-C
Contributor

Polynomial-C commented May 7, 2018

As of freetype-2.9.1 the freetype-config script no longer gets installed
by default.

See also Make installation of `freetype-config' optional commit by freetype upstream.

Prefer pkg-config over freetype-config if possible
As of freetype-2.9.1 the freetype-config script no longer gets installed
by default.
@Polynomial-C

This comment has been minimized.

Show comment
Hide comment
@Polynomial-C

Polynomial-C May 7, 2018

Contributor

Calling pkg-config directly might break cross-compilation but I didn't bother to work on this as the configure script already calls pkg-config directly somewhere else.

Contributor

Polynomial-C commented May 7, 2018

Calling pkg-config directly might break cross-compilation but I didn't bother to work on this as the configure script already calls pkg-config directly somewhere else.

@bgK

This comment has been minimized.

Show comment
Hide comment
@bgK

bgK May 8, 2018

Member

At one point, in residualvm we used pkg-config to detect GLEW. Users were confused because they installed GLEW using macports / homebrew and it was still not found. What we didn't tell them is that they also needed to install pkg-config. In my opinion, there should be a check / warning / something to help users know they are missing pkg-config.

Member

bgK commented May 8, 2018

At one point, in residualvm we used pkg-config to detect GLEW. Users were confused because they installed GLEW using macports / homebrew and it was still not found. What we didn't tell them is that they also needed to install pkg-config. In my opinion, there should be a check / warning / something to help users know they are missing pkg-config.

@bgK

This comment has been minimized.

Show comment
Hide comment
@bgK

bgK May 8, 2018

Member

Calling pkg-config directly might break cross-compilation but I didn't bother to work on this as the configure script already calls pkg-config directly somewhere else.

Won't that be a problem on buildbot as soon as this is merged? I don't have access to the server to check, but configure will likely use the host pkg-config, find the host version of freetype, and use incorrect flags to build the cross compiled targets.

Member

bgK commented May 8, 2018

Calling pkg-config directly might break cross-compilation but I didn't bother to work on this as the configure script already calls pkg-config directly somewhere else.

Won't that be a problem on buildbot as soon as this is merged? I don't have access to the server to check, but configure will likely use the host pkg-config, find the host version of freetype, and use incorrect flags to build the cross compiled targets.

@eli-schwartz

This comment has been minimized.

Show comment
Hide comment
@eli-schwartz

eli-schwartz May 8, 2018

pkg-config supports PKG_CONFIG_PATH for prioritizing the directory to read freetype.pc from. People who are cross-compiling software and wish to use dependencies that are not from the default, native system path should be setting this variable.

It also transparently supports using custom versions of things, e.g. for openssl 1.1 Arch Linux ships an openssl-1.0 compat package for old software, which means by setting (or prepending to) PKG_CONFIG_PATH, it becomes trivial to swap in a different library for basically anything, in one place, as long as you support pkg-config. No need for hacks like mucking around with $PATH and probably overriding lots more than just the *-config scripts.

There is a reason pkg-config is the standard. Because it works. It lets you define where you want to get your XXX from, it orders flags for you, it lets you transparently add recursive library dependencies for both --static and non-static builds as defined by the very simple, clear .pc grammar, etc. etc. etc.

Currently this software definitively breaks on Arch Linux, and users are reporting bugs to us. But pkg-config support has been around for a long time, it's the ideal way to detect dependencies, and we don't plan on re-enabling the legacy shellscript. So downstream projects need to (finally!) migrate to pkg-config.

Other distros will almost certainly do the same thing, sooner or later.

Note that linux distros will usually have pkg-config installed by default:

  • as part of a "building packages metapackage", e.g. on Arch Linux it is part of base-devel
  • on Gentoo which is a source-based distro it should be part of the system profile
  • on Debian and Fedora it seems to be a dependency of the various -devel packages containing headers, if the devel package has .pc files

For the rest, this is what wiki instructions are for. The current macOS instructions even explain the need for manually installing pkg-config if using fluidsynth.

pkg-config supports PKG_CONFIG_PATH for prioritizing the directory to read freetype.pc from. People who are cross-compiling software and wish to use dependencies that are not from the default, native system path should be setting this variable.

It also transparently supports using custom versions of things, e.g. for openssl 1.1 Arch Linux ships an openssl-1.0 compat package for old software, which means by setting (or prepending to) PKG_CONFIG_PATH, it becomes trivial to swap in a different library for basically anything, in one place, as long as you support pkg-config. No need for hacks like mucking around with $PATH and probably overriding lots more than just the *-config scripts.

There is a reason pkg-config is the standard. Because it works. It lets you define where you want to get your XXX from, it orders flags for you, it lets you transparently add recursive library dependencies for both --static and non-static builds as defined by the very simple, clear .pc grammar, etc. etc. etc.

Currently this software definitively breaks on Arch Linux, and users are reporting bugs to us. But pkg-config support has been around for a long time, it's the ideal way to detect dependencies, and we don't plan on re-enabling the legacy shellscript. So downstream projects need to (finally!) migrate to pkg-config.

Other distros will almost certainly do the same thing, sooner or later.

Note that linux distros will usually have pkg-config installed by default:

  • as part of a "building packages metapackage", e.g. on Arch Linux it is part of base-devel
  • on Gentoo which is a source-based distro it should be part of the system profile
  • on Debian and Fedora it seems to be a dependency of the various -devel packages containing headers, if the devel package has .pc files

For the rest, this is what wiki instructions are for. The current macOS instructions even explain the need for manually installing pkg-config if using fluidsynth.

@bgK

This comment has been minimized.

Show comment
Hide comment
@bgK

bgK May 10, 2018

Member

I tried this with the PlayStation 3 toolchain I have installed. I used to configure the build using ../configure --host=ps3. The script would find the PS3 libraries using the environment variables defined by the toolchain: https://github.com/ps3dev/ps3toolchain/blob/71e9c0222ca4f0d3041a45b6821c05f390b27fa3/readme.txt#L29.
With this change I need to do PKG_CONFIG_PATH=$PS3DEV/portlibs/ppu/lib/pkgconfig/ ../configure --host=ps3.

What do you think is the proper approach?

  • Change configure to append the toolchain pkg-config path to the user defined PKG_CONFIG_PATH environment variable before passing it to pkg-config.
  • Tell the porters to properly define PKG_CONFIG_PATH for their build environment and alter the buildbot configuration for all the toolchains.
Member

bgK commented May 10, 2018

I tried this with the PlayStation 3 toolchain I have installed. I used to configure the build using ../configure --host=ps3. The script would find the PS3 libraries using the environment variables defined by the toolchain: https://github.com/ps3dev/ps3toolchain/blob/71e9c0222ca4f0d3041a45b6821c05f390b27fa3/readme.txt#L29.
With this change I need to do PKG_CONFIG_PATH=$PS3DEV/portlibs/ppu/lib/pkgconfig/ ../configure --host=ps3.

What do you think is the proper approach?

  • Change configure to append the toolchain pkg-config path to the user defined PKG_CONFIG_PATH environment variable before passing it to pkg-config.
  • Tell the porters to properly define PKG_CONFIG_PATH for their build environment and alter the buildbot configuration for all the toolchains.
@eli-schwartz

This comment has been minimized.

Show comment
Hide comment
@eli-schwartz

eli-schwartz May 10, 2018

If your configure script already sets up the toolchain for them, it makes sense to set PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/path/to/libdir/pkgconfig" too.

If your configure script already sets up the toolchain for them, it makes sense to set PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/path/to/libdir/pkgconfig" too.

@Polynomial-C

This comment has been minimized.

Show comment
Hide comment
@Polynomial-C

Polynomial-C Jun 4, 2018

Contributor

So is there anything I can do to speed up merging of this PR?

Contributor

Polynomial-C commented Jun 4, 2018

So is there anything I can do to speed up merging of this PR?

@rsn8887

This comment has been minimized.

Show comment
Hide comment
@rsn8887

rsn8887 Jun 5, 2018

Contributor

Unless I misunderstand something, I am pretty sure this will break freetype support on Vita on the current buildbot config. I think this should be thoroughly tested on all relevant platforms before merging. Maybe you could put something in there that causes a fallback to the old method (free type config) if the new method (pkg config) doesn't find freetype or fails for some other reason.

Contributor

rsn8887 commented Jun 5, 2018

Unless I misunderstand something, I am pretty sure this will break freetype support on Vita on the current buildbot config. I think this should be thoroughly tested on all relevant platforms before merging. Maybe you could put something in there that causes a fallback to the old method (free type config) if the new method (pkg config) doesn't find freetype or fails for some other reason.

@Polynomial-C

This comment has been minimized.

Show comment
Hide comment
@Polynomial-C

Polynomial-C Jun 6, 2018

Contributor

I have tried to make this not break on systems that don't have pkg-config installed. Just look at the find_freetype function in my patch. The only issue I can see is systems that cross-compile scummvm and thus need pkg-config from the target system rather than the host system. But I am quite sure this is already broken as the configure script already calls pkg-config to check for libunity.

Contributor

Polynomial-C commented Jun 6, 2018

I have tried to make this not break on systems that don't have pkg-config installed. Just look at the find_freetype function in my patch. The only issue I can see is systems that cross-compile scummvm and thus need pkg-config from the target system rather than the host system. But I am quite sure this is already broken as the configure script already calls pkg-config to check for libunity.

@eli-schwartz

This comment has been minimized.

Show comment
Hide comment
@eli-schwartz

eli-schwartz Jun 6, 2018

The only issue I can see is systems that cross-compile scummvm and thus need pkg-config from the target system rather than the host system. But I am quite sure this is already broken as the configure script already calls pkg-config to check for libunity.

Properly supporting this is in fact the very reason Debian convinced Freetype to drop the freetype-config script. :D

The custom is to try running $PKG_CONFIG, defaulting to pkg-config, but on multi-arch/cross-compiler builds the builder should be setting PKG_CONFIG=${CHOST}-pkg-config which will be a wrapper script, see e.g. https://autotools.io/pkgconfig/cross-compiling.html

The pkg-config binary itself can come from anywhere as the only host vs. target dependent information is some default strings it uses for the sysroot/libdir, and it's all configurable via the environment variables documented in its manpage.

The only issue I can see is systems that cross-compile scummvm and thus need pkg-config from the target system rather than the host system. But I am quite sure this is already broken as the configure script already calls pkg-config to check for libunity.

Properly supporting this is in fact the very reason Debian convinced Freetype to drop the freetype-config script. :D

The custom is to try running $PKG_CONFIG, defaulting to pkg-config, but on multi-arch/cross-compiler builds the builder should be setting PKG_CONFIG=${CHOST}-pkg-config which will be a wrapper script, see e.g. https://autotools.io/pkgconfig/cross-compiling.html

The pkg-config binary itself can come from anywhere as the only host vs. target dependent information is some default strings it uses for the sysroot/libdir, and it's all configurable via the environment variables documented in its manpage.

@sev-

This comment has been minimized.

Show comment
Hide comment
@sev-

sev- Aug 3, 2018

Member

Closing this for the sake of #1267

Member

sev- commented Aug 3, 2018

Closing this for the sake of #1267

@sev- sev- closed this Aug 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment