The issue applies and is reproducible for all versions 2.6 through 3.5.

This is the changeset we applied to all FreeBSD Ports to fix the issue:

https://svnweb.freebsd.org/ports?view=revision&revision=326729

One specific example (Python 3.3):

1) Use CPPFLAGS over CFLAGS (See before *and* after comments):

  https://svnweb.freebsd.org/ports/head/lang/python33/Makefile?r1=326729&r2=326728&pathrev=326729

2) Revert the absolutely crazy complexity in Makefile.pre.in by stripping out CONFIGURE_*, allowing once again
./configure to substitute the right variables based on what has been passed to it:

  https://svnweb.freebsd.org/ports/head/lang/python33/files/patch-Makefile.pre.in?r1=326729&r2=326728&pathrev=326729

This results in:

Makefile.pre.in:
  CPPFLAGS=       @CPPFLAGS@ <-- YAY!
  PY_CPPFLAGS=    $(BASECPPFLAGS) -I. -IInclude -I$(srcdir)/Include $(CPPFLAGS) <-- YAY
  
Makefile:
  CPPFLAGS=       -I/usr/local/include - YAY!
  PY_CPPFLAGS=    $(BASECPPFLAGS) -I. -IInclude -I$(srcdir)/Include $(CPPFLAGS) <-- YAY!

The root cause *requiring* the use of CPPFLAGS, is PY_CFLAGS before PY_CPPFLAGS here:

  PY_CORE_CFLAGS= $(PY_CFLAGS) $(PY_CPPFLAGS) $(CFLAGSFORSHARED) -DPy_BUILD_CORE

As per https://www.gnu.org/prep/standards/html_node/Command-Variables.html

"Put CFLAGS last in the compilation command, after other variables containing compiler options, so the user can use CFLAGS to override the others."

We must use CPPFLAGS, because CFLAGS has been broken in one way or another for a long time. The target state is *both* must just work.

This can only happen if the standard user-serviceable autoconf and Makefile variables are left alone, not extended or overridden, and behave in exactly the same way whether provided in the environment for *either* ./configure, make, or *both*.

For the most recent chapter in the C[PP|LD]FLAGS/Makefile book, see: 92a9dc668c95 from #9189 which was sound in intent, but in execution left us deeper down the rabbit-hole.

Moving forward and as a first step, what does everyone think of switching the order of
$(PY_CFLAGS) $(PY_CPPFLAGS) in PY_CORE_CFLAGS= ?

I hope (but I'm not holding my breath) that nothing relies on the current ordering.