Unexpected Mac X11 dependency

[Dan Smith]

I'm trying to do a vanilla build on Mac OS X Mavericks.  (Using an old copy of Xcode 4.)

Configure succeeds as follows, while acknowledging that X11 is not found:

sh configure --with-boot-jdk=$JAVA7_HOME --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin
...
checking what is not needed on MacOSX?... alsa pulse x11
checking for Mac OS X Java Framework... /System/Library/Frameworks/JavaVM.framework
checking for X... no
checking for X11/extensions/shape.h... no
...

Building jdk gets a compiler error, complaining about a missing X11 header:

make all
...
In file included from /Users/dan/Dev/jdk/jdk8/jdk/src/share/native/sun/java2d/pipe/Region.h:34,
                 from /Users/dan/Dev/jdk/jdk8/jdk/src/share/native/sun/java2d/loops/Blit.c:27:
/Users/dan/Dev/jdk/jdk8/jdk/src/solaris/native/sun/awt/utility/rect.h:31:22: warning: X11/Xlib.h: No such file or directory
In file included from /Users/dan/Dev/jdk/jdk8/jdk/src/share/native/sun/java2d/pipe/Region.h:34,
                 from /Users/dan/Dev/jdk/jdk8/jdk/src/share/native/sun/java2d/loops/Blit.c:27:
/Users/dan/Dev/jdk/jdk8/jdk/src/solaris/native/sun/awt/utility/rect.h:32: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘RECT_T’
...

As I understand it, all dependencies on X11 were supposed to have been removed at the end of October.  (Attempts to run configure on earlier versions fail, telling me I need X11.)

I'm no expert on how these things are structured, but I find it odd that a file in src/solaris needs to be compiled by a Mac build (shouldn't it only depend on src/share and src/macosx?)...

For now, my workaround is to add a compiler flag at configure time:

sh configure \
  --with-boot-jdk=$JAVA7_HOME \
  --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin \
  --with-extra-cflags=-I/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/X11/include

But it would be helpful if this inconsistency could be addressed, either by i) removing the dependency (I think this is what is intended), or ii) enforcing the dependency at configure time.

—Dan