René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"setupext should not explicitly add /usr/{,local/}include to the include path","articleBody":"\u003c!--To help us understand and resolve your issue, please fill out the form to the best of your ability.--\u003e\r\n\u003c!--You can feel free to delete the sections that do not apply.--\u003e\r\n\r\n### Bug report\r\n\r\n**Bug summary**\r\n\r\nCurrently, on Linux, setupext.py explicitly adds /usr/{,local/}include to the search path (because it is listed in get_base_dirs).  This can be confirmed by checking e.g. the output of `python setup.py build`.\r\nThis makes it impossible to compile matplotlib using a non-system compiler (e.g., anaconda now provides gcc7.2, see https://www.anaconda.com/blog/developer-blog/utilizing-the-new-compilers-in-anaconda-distribution-5/) that comes with its own headers (in /path/to/env/lib/gcc/x86_64-conda_cos6-linux-gnu/7.2.0/include) which may be incompatible with the system headers.  Note that conda's gcc is configured to indeed look into its own headers directory instead of /usr/include.\r\n\r\nIn the specific case of gcc7.2.0 from anaconda, explicitly adding /usr/include causes it to use /usr/include/math.h instead of its own math.h; Ubuntu's /usr/include/math.h is incompatible because it tries to include bits/mathdef.h and this file is under /usr/lib/gcc/x86_64-linux-gnu/5/include, which is part of the default path of the *system* gcc but not the conda gcc.\r\n\r\nWe currently explicitly look up these default paths to check that the include files are actually present, as a fallback in case they exist but no pkg-config information is present.  I propose instead to require pkg-config information to be present (as a check that the package is indeed installed) and not try to manually look for the headers.\r\n\r\nThis would cause a build failure if there is some linux distro that includes the headers for our dependencies *without* including the pkg-config info, which I am happy to claim to be a bad idea.\r\n\r\nThis would also mean that if one is using a non-system compiler (e.g., a conda compiler), then one would also need to install freetype/libpng/zlib in a place this compiler knows about (e.g., via a conda package) rather than relying on the system version.  Here too I think this is a reasonable restriction (if you know to set up your own non-system compiler you should know how to set up the dependencies properly too...).\r\n\r\n**Code for reproduction**\r\n\r\n```\r\n$ conda create -n test -c conda-forge numpy freetype \u0026\u0026 source activate test \u0026\u0026 conda install -yc anaconda gxx_linux-64\r\n$ \u003cfrom matplotlib source\u003e python setup.py build\r\n```\r\n\r\n**Actual outcome**\r\n\r\n```\r\n/home/alee/miniconda3/envs/test/bin/x86_64-conda_cos6-linux-gnu-cc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -DFREETYPE_BUILD_TYPE=system -DPY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib_ft2font_ARRAY_API -DNPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION -D__STDC_FORMAT_MACROS=1 -I/home/alee/miniconda3/envs/test/lib/python3.6/site-packages/numpy/core/include -I/home/alee/miniconda3/envs/test/include/freetype2 -I/usr/local/include -I/usr/include -I. -I/home/alee/miniconda3/envs/test/include/python3.6m -c src/ft2font.cpp -o build/temp.linux-x86_64-3.6/src/ft2font.o\r\nIn file included from /home/alee/miniconda3/envs/test/include/python3.6m/pyport.h:194:0,\r\n                 from /home/alee/miniconda3/envs/test/include/python3.6m/Python.h:50,\r\n                 from src/mplutils.h:31,\r\n                 from src/ft2font.cpp:9:\r\n/usr/include/math.h:31:10: fatal error: bits/math-vector.h: No such file or directory\r\n #include \u003cbits/math-vector.h\u003e\r\n          ^~~~~~~~~~~~~~~~~~~~\r\ncompilation terminated.\r\nerror: command '/home/alee/miniconda3/envs/test/bin/x86_64-conda_cos6-linux-gnu-cc' failed with exit status 1\r\n```\r\n\r\n**Expected outcome**\r\n\r\nSuccessful compilation.  In the example above, this can be achieved by patching setupext's get_base_dirs to return an empty list -- this works because pkg-config info is available for all packages (so we don't do any manual header lookup ourselves), giving information to gcc about where to find the headers.\r\n\r\n**Matplotlib version**\r\n\u003c!--Please specify your platform and versions of the relevant libraries you are using:--\u003e\r\n  * Operating system: Ubuntu\r\n  * Matplotlib version: master\r\n  * Matplotlib backend (`print(matplotlib.get_backend())`): N/A\r\n  * Python version: 3.6\r\n  * Jupyter version (if applicable): N/A\r\n  * Other libraries: N/A\r\n\r\n\u003c!--Please tell us how you installed matplotlib and python e.g., from source, pip, conda--\u003e\r\n\u003c!--If you installed from conda, please specify which channel you used if not the default--\u003e\r\n\r\n-----\r\n\r\nxref https://github.com/matplotlib/matplotlib/issues/3821 as well (ultimately we won't have /usr/local appear explicitly anywhere anymore in setupext.py).\r\n","author":{"url":"https://github.com/anntzer","@type":"Person","name":"anntzer"},"datePublished":"2017-11-10T02:24:01.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/9737/matplotlib/issues/9737"}