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...

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.

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

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...

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

The point here is to notparse 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.

attn@sandrotosi

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

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 dopkg-config --cflags --libs freetype >= 2.3 andpkg-config --cflags --libs libpng >= 1.2. Though maybe you'll still require the check for Windows?

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.

@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, seehttps://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.)

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

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

@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.

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