<AWT Dev> [9] Request for Review: 8003900: X11 dependencies should be removed from Mac OS X build.

[Artem Ananiev]

On 5/12/2014 3:53 PM, Anthony Petrov wrote:
> Hi David,
>
> The fix looks good to me. To answer your questions:
>
> 1. Using the XAWT macro is correct. It is only defined if we're building
> the XToolkit, which we don't on the Mac. However, everywhere else we
> actually check

XAWT is a legacy macro, which was introduced to share code between 
XToolkit and MToolkit on Linux/Solaris. At the moment, XAWT is always 
defined on Linux/Solaris and never defined on Mac OS X, so checks 
against XAWT and MACOSX are interchangeable. In the future, if we 
support anything besides X11 on Linux/Solaris, XAWT may be of some use 
again, but MACOSX meaning is unlikely to change. So my preference would 
be to use MACOSX rather than !XAWT.

Thanks,

Artem

> #ifdef MACOSX
> // ... do Mac stuff
> #else
> // ... do X11/Linux/Solaris/etc. stuff
> #endif
>
> We're unlikely to start supporting XToolkit/XAWT on Mac in the future,
> so is there a reason not to use the MACOSX macro instead for consistency
> with the rest of the code?
>
>
> 2. Regarding factoring out the X11 code: firstly we need to rename
> src/solaris/ to src/_nix/ (where _nix could stand for UNIX and whatnot).
> In that case, moving X11-specific code and OSX-specific code into their
> corresponding directories would make sense. Obviously, this is a huge
> project and I don't see this happening any time soon.
>
> --
> best regards,
> Anthony
>
> On 5/9/2014 7:36 AM, David DeHaven wrote:
>>
>> JBS issue:
>> https://bugs.openjdk.java.net/browse/JDK-8003900
>>
>> Summary:
>> The X11 toolkit was disabled on the Mac but the dependency was not
>> completely removed for the release of 8.
>>
>> This ended up being a lot simpler than I'd anticipated, but I have a
>> couple questions:
>> 1> I've surrounded X dependent code with #ifdef XAWT blocks, I'm not
>> entirely sure if this is proper (it appears to be...)
>> 2> I have thoughts that maybe the X11 dependent code should be
>> factored out into a X specific location rather than just disabled or
>> worked around in the code. The code seems pretty well ingrained, so
>> this may be a larger task than necessary.
>>
>>
>> To validate the removal of the X11 dependency, I did the following:
>>
>> Preparation:
>> - Copied /opt/X11 (installed by XQuartz) to somewhere I could readily
>> modify, let's call it ~/java/X11-good
>> - Made a second copy to ~/java/X11-bad
>> - Modified the header files in ~/java/X11-bad, adding #error
>> statements to cause compilation to abort if any are included
>> - Created a symlink to ~/java/X11-good at ~/java/X11
>> - Removed /opt/X11 and the /usr/X11 symlink, the latter is important
>> as that's one of the locations that configure searches
>>
>> To validate building with no X11 headers or libs:
>> - Ran configure with no special arguments, it was not able to find X
>> headers
>> - Ran "make jdk", ran SwingSet2.jar, everything was happy
>>
>> To validate building *with* X11 headers and libs, but XAWT disabled
>> (as it should be on Mac):
>> - Ran "configure --x-includes=~/java/X11/include
>> --x-libraries=~/java/X11/lib", configure found X headers
>> - Ran "make clean-jdk jdk", ran SwingSet2.jar, everything was happy
>>
>> To validate the above configuration does not actually USE X11:
>> - Changed the ~/java/X11 symlink to point to ~/java/X11-bad
>> - Ran "make clean-jdk jdk", ran SwingSet2.jar, everything was still happy
>>
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ddehaven/8003900/jdk.0/
>>
>> I submitted a JPRT run with this and the patch for 8042440 applied and
>> there were three failures, two in crypto tests (solaris/sparc9) and
>> one on windows due to a network issue (transient issue?). None of the
>> failures were relevant to AWT or Java2D or X11 in general. There were
>> no build failures.
>>
>> -DrD-
>>