Although #1632 reported a problem with the freetype headers as well, I don't think these problems are related to this.

The real question is why pkg-config isn't finding them. What does the output of pkg-config freetype2 --cflags say?

Nono, pkg-config IS finding freetype2, but matplotlib restricts its search for ft2build.h only to the directories reported by pkg-config, whereas ft2build.h is in the standard /usr/include folder.

Hmm, my setup is exactly the same and it works fine. Both on OS X and on Ubuntu.

$ pkg-config freetype2 --cflags
-I/opt/local/include/freetype2 -I/opt/local/include

All my freetype stuff is in /opt/local/include/freetype2 except ft2build.h, which is in /opt/local/include. My point is that pkg-config should still be picking up the ft2build.h file in the parent directory, so that matplotlib restricting to the paths returned by pkg-config is exactly what it should be doing.

Your setup seems to be far from being exactly the same. It appears that you manually installed freetype2, which ended up in /opt/local/include. Your pkg-config reflects that. The default package managed setup is to have the headers installed in /usr/include. The headers installed in the subdirectory /usr/include/freetype2 require an include directive as reported by pkg-config

$ pkg-config freetype2 --cflags
-I/usr/include/freetype2

The ft2build.h is in /usr/include which doesn't need to be added to the cflags as it is the default header search path. The way setupext.py is trying to verify the freetype2 setup by looking at the additional include directories only doesn't work in this case.

One could either keep the system as it is and look for another freetype header that is located in /usr/include/freetype2, or try to compile a small code snippet that includes freetype (like the autoconf tools do).

Ah, the reason why this is showing up now is because I switched from matplotlib 1.2 to master, to which @mdboom applied some major restructuring in 6aa7b29.

@pwuertz: What's the exact error message you're getting?

What the new setup code (in master) does is look in both the standard directories (as reported by Python) and what pkg-config returns. The old version only looked in pkg-config, and displayed a warning (but continued) if a header file wasn't to be found there. So I'd think the new version to be more robust to this kind of issue. But perhaps on Ubuntu, Python doesn't explicitly provide the standard directories? I agree that the only way to really do this right is to probably do a test compile, but I was trying to avoid that due to how complex distutils makes that (since we'd have to do the test build with the compiler distutils chose and the same environment etc...)

@pwuertz Aha, it only adds the extra flag for nondefault locations. I see now. Then yes, this is a problem. I see this behaviour on a separate machine where the package was installed into the default location.

@mdboom How would one check the standard directories as reported by Python? For me, the 'obvious' places don't have the default /usr/local listed:

In [2]: print sys.prefix
/opt/apps/ossw/applications/python/python-2.7.3/sl6

In [3]: print sys.path
['', '/opt/apps/ossw/applications/python/python-2.7.3/sl6/bin', '/h1/damon/python/lib/docopt-0.5.0-py2.7.egg', '/h1/damon', '/h1/damon/python/lib', '/opt/apps/ossw/applications/python/python-2.7.3/sl6/lib/python27.zip', '/opt/apps/ossw/applications/python/python-2.7.3/sl6/lib/python2.7', '/opt/apps/ossw/applications/python/python-2.7.3/sl6/lib/python2.7/plat-linux2', '/opt/apps/ossw/applications/python/python-2.7.3/sl6/lib/python2.7/lib-tk', '/opt/apps/ossw/applications/python/python-2.7.3/sl6/lib/python2.7/lib-old', '/opt/apps/ossw/applications/python/python-2.7.3/sl6/lib/python2.7/lib-dynload', '/opt/apps/ossw/applications/python/python-2.7.3/sl6/lib/python2.7/site-packages', '/opt/apps/ossw/applications/python/python-2.7.3/sl6/lib/python2.7/site-packages/gtk-2.0', '/opt/apps/ossw/applications/python/python-2.7.3/sl6/lib/python2.7/site-packages/IPython/extensions']

Sorry -- I was wrong -- it's not actually extracting the directories that distutils sends to the compiler by the default -- we're using a set of hardcoded paths in addition to what pkg-config returns -- but /usr/include is among those, so it's still a mystery.

If you do

In [1]: import setupext

In [2]: setupext.get_base_dirs()
Out[2]: ['/usr/local', '/usr']

In [4]: ext.include_dirs
Out[4]: ['/usr/include', '.']

What do you get?

Sorry... copy-and-paste error. I meant to say:

In [1]: import setupext

In [3]: ext = setupext.make_extension("foo", [])                                                                                                                                                       

In [4]: ext.include_dirs
Out[4]: ['/usr/include', '.']

I think I tracked it down to options['basedirlist'] which is read from setup.cfg. If the config file says

# Uncomment to override the default basedir in setupext.py.
# This can be a single directory or a space-delimited list of directories.
basedirlist = /usr

the options['basedirlist'] is just the string '/usr' instead of ['/usr'] and get_base_dirs() returns that. make_extension() then tries to iterate over the characters of the string and thus doesn't find the /usr/include dir, so no default includes are appended. Uncommenting this line in setup.cfg makes the whole thing work again.

Ah -- I see. At the very least, the example given in setup.cfg.template needs to be updated. For extra credit, we should probably make basedirlist convert a single string to a list with one entry (providing a string is just too easy).

Huzzah! Thanks @mdboom.

Self assigning. I hope to get a fix in later today.

👍 LGTM

@pwuertz: Once you've confirmed this fixes things for you, why don't you take the honors of pushing the big green button...

Confirmed, thanks @mdboom !