DEVELOPER_DIR is an internal variable of configure. I'm afraid it is not for a variable to be overwritten via command line. (If it were so, configure would check the value $DEVELOPER_DIR before assigning a certain value to the variable.)

Since the name of the variable happens to be the same as that of an environmental variable for xcrun, both configure and xcrun are made confused by the command line

$ DEVELOPER_DIR=`xcode-select -print-path` ./configure

Here, xcrun is relevant because /usr/bin/gcc is not a real gcc but a stub to invoke a true gcc with the help of xcrun whose behavior depends on DEVELOPER_DIR when it is defined.

That's why a number of messages like

xcrun: error: missing DEVELOPER_DIR path: 

are left in config.log just after gcc is invoked.

Obviously, this implies that the usage of DEVELOPER_DIR in question makes /usr/bin/gcc completely useless. (If necessary, try

$ DEVELOPER_DIR="" gcc --version

to make sure.)

In fact, I observed that configure had been giving "no" to almost all of the checks long before the failure of the terminal library detection finally killed configure.

Since it is clear that there's a risk for DEVELOPER_DIR to interfere with xcrun's environmental variable, it might make sense to rename it.

In the first place, we still must support building Vim on OS X 10.4? These configure script stuff is actually interference. I don't think --with-developer-dir=PATH option is needed (DEVELOPER_DIR environment variable works).

Ok, that's fine. Still my patch is correct way to fix the issue.