Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Simplify version checks for freetype and libpng. #11983

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

Merged
merged 1 commit into from
Dec 30, 2018

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Aug 30, 2018

Currently, setupext.py replicates a lot of work done by the compiler to
check whether header files are present, and whether freetype and libpng
have sufficiently recent versions.

Instead, we can just add a small stub source file at the top of the
extension sources which just tries to include the header and checks the
version macros. If the header is not found, compilation will
immediately abort with foo.h: No such file or directory; if the
version is too old, we can emit an appropriate error message (#pragma message
is supported by all major compilers and allows expanding of
macros in the error message).

Work related to #9737 (the goal being to not list the include paths ourselves).

PR Summary

PR Checklist

  • Has Pytest style unit tests
  • Code is Flake 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@anntzer anntzer added the Build label Aug 30, 2018
@tacaswell tacaswell added this to the v3.1 milestone Aug 30, 2018
@tacaswell tacaswell requested review from mdboom and QuLogic August 30, 2018 16:33
@mdboom
Copy link
Member

mdboom commented Aug 30, 2018

Seems fine, but we lose the ability to display the version in the event of things working, no? Probably not the end of the world, though...

@anntzer
Copy link
Contributor Author

anntzer commented Aug 30, 2018

I can add a #pragma message ... displaying the version in the case things are working as well, though I'm not really convinced of the utility of the thing. Let me know if you'd like that.

@tacaswell
Copy link
Member

Seeing the version number is helpful to make sure it found the right one (ex conda vs system versions).

@anntzer
Copy link
Contributor Author

anntzer commented Aug 31, 2018

Sure, I always emit it now. It's no longer at the top but having the compiler do the job of figuring out what file to include (... and not trying to parse freetype.h ourselves just for the purpose of finding its version...) is the whole point of this PR, so...

Copy link
Member

@QuLogic QuLogic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pkg-config is the defacto standard on Linux, so I don't really agree with not using it here. I can get behind dropping freetype-config as it's not really used in modern systems. And if you want to ignore pkg-config on Windows, I guess that's fine.


#pragma message "Compiling with FreeType version " \
XSTR(FREETYPE_MAJOR) "." XSTR(FREETYPE_MINOR) "." XSTR(FREETYPE_PATCH) "."
#if FREETYPE_MAJOR << 16 + FREETYPE_MINOR << 8 + FREETYPE_PATCH < 0020300
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is octal; I think you want 0x020300, which would match the bitshifts.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed, fixed

@QuLogic
Copy link
Member

QuLogic commented Aug 31, 2018

And I'm also confused, because your original post in #9737 said that we should require pkg-config and drop everything else.

@anntzer
Copy link
Contributor Author

anntzer commented Aug 31, 2018

The point here is to not parse the output of pkg-config to try and figure out what is the full include path, find ourselves whether the header is present, and parse the freetype version from freetype.h. This is problematic because we try to do this even if pkg-config is not present, which leads to us manually adding "standard" include paths (/usr/include, /usr/local/include), which causes problems with cross-compilation (as reported recently on gitter) or using conda's gcc (which also uses a separate prefix).

The plan is definitely to still use pkg-config/freetype-config/libpng-config to get the correct compile and link flags (in fact that's more or less needed for freetype, as the standard install needs -I$prefix/include/freetype2), but then just shove all that into extra_compile_args/extra_link_args and let the compiler do its job.

@anntzer anntzer mentioned this pull request Sep 1, 2018
6 tasks
@tacaswell
Copy link
Member

attn @sandrotosi

@anntzer
Copy link
Contributor Author

anntzer commented Sep 27, 2018

Re-pinging @QuLogic @sandrotosi after #11983 (comment). Thanks in advance for your input.

@QuLogic
Copy link
Member

QuLogic commented Oct 4, 2018

If we're going to ultimately rely on pkg-config, then I don't think the C macro thing is required at all. We can do pkg-config --cflags --libs freetype >= 2.3 and pkg-config --cflags --libs libpng >= 1.2. Though maybe you'll still require the check for Windows?

@anntzer
Copy link
Contributor Author

anntzer commented Oct 4, 2018

The macro-checking is useful both for windows, and for unices in case you don't have pkg-config installed but are passing all flags in manually using $CFLAGS/$LDFLAGS/$CPLUS_INCLUDE_PATH/etc.

@anntzer
Copy link
Contributor Author

anntzer commented Oct 12, 2018

@QuLogic Are you still rejecting the patch after the discussion above?
Also note that relying on pkg-config to get the freetype version would result in more less informative messages, because the freetype pkg-config (libtool) version is completely unrelated to its release version, see https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/docs/VERSIONS.TXT#n45 for a table, and embedding a conversion table for these seems completely overkill, especially as we'll have the release versions as macros during the compilation anyways. (But for future reference if this is needed, manually inspecting the 2.3.0 release (our current oldest-supported version) shows that its libtool version is 9.11.3.)

@anntzer
Copy link
Contributor Author

anntzer commented Nov 24, 2018

Re-ping @QuLogic (even if you still reject after the discussion above, please leave a comment as to why, thanks!).

Copy link
Member

@QuLogic QuLogic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll approve, tentatively to the pkg-config re-enablement you mentioned you'd do.

Currently, setupext.py replicates a lot of work done by the compiler to
check whether header files are present, and whether freetype and libpng
have sufficiently recent versions.

Instead, we can just add a small stub source file at the top of the
extension sources which just tries to include the header and checks the
version macros.  If the header is not found, compilation will
immediately abort with `foo.h: No such file or directory`; if the
version is too old, we can emit an appropriate error message (`#pragma
message` is supported by all major compilers and allows expanding of
macros in the error message).
@anntzer
Copy link
Contributor Author

anntzer commented Dec 29, 2018

(rebased and force pushed additional parentheses in #pragma message() to avoid a harmless warning with msvc)

@anntzer
Copy link
Contributor Author

anntzer commented Dec 29, 2018

@QuLogic Thanks. To be clear, the end result should look like #13064, where you can see that the check for pkg-config version (using --atleast-version now, instead of parsing ourselves) is present.

@tacaswell
Copy link
Member

Going to merge this to un-block the stack of 3 PRs (this on, #11964 and #13064)

@tacaswell tacaswell merged commit d1060a8 into matplotlib:master Dec 30, 2018
@anntzer anntzer deleted the builddepchecks branch December 30, 2018 21:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants