Setup.py evaluates what's given in LDFLAGS and CPPFLAGS and CFLAGS. These variables are the usual mechanism to communicate custom paths/libs/defs to a build process. However, setup.py puts system paths in front of custom paths which makes it impossible to use these variables for providing search paths to overwrite system settings.

This patch puts system paths at the end of the list to avoid this problem.  Is there a rationale for prepending system paths?

I've been doing some research on this, the below is pretty much a brain-dump.

Related issues: issue232609, issue420565, issue10520.

This looks to me like the ideal solution is to assign a priority to each entry and sort by that priority before using it; give system locations low priority, /usr/local (sys.prefix) locations slightly higher priority, and user-defined paths highest priority.  That may be far more complex than it's worth, though.

It looks like setup.py doesn't actually look at CFLAGS at all, just CPPFLAGS and LDFLAGS.

Chris, is the behavior of 3.x any better for you?  There are some differences between the 2.7 and 3.x implementations of add_dir_to_list (most obviously, relative paths are always kept at the front of the list; see issue10520).

The naive solution looks to me to be to just move the CPPFLAGS/LDFLAGS checking further down detect_modules(), past all other calls to add_dir_to_list.  A test build with that change seems to work for me, but I'm not familiar enough with setup.py and how it works to call it correct.

Zach, 

3.x had the desired behavior.  We didn't have to make any changes.

In that case, does this patch do what you want it to do?

I should be able to try it out today or tomorrow.  I'll let you know.

Fixed in Python 3 (in https://github.com/python/cpython/commit/807bd0a8a47191f7aa25cd9d5619bbc46a3f2a2a). Too late for 2.7.