Request for review: 7039182 NIO platform specific files

[Kelly O'Hair]

Looks fine.

-kto

On Jun 27, 2011, at 12:28 AM, David Holmes wrote:

> Thanks Kelly. Updated webrev at:
> 
> http://cr.openjdk.java.net/~dholmes/7039182/webrev.1/
> 
> David
> 
> Kelly O'Hair said the following on 06/23/11 02:35:
>> Things like this:
>> 884 $(SFS_GEN)/SolarisConstants.java:
>> 885         $(prep-target)
>> 886         $(CP) $(NIO_PLATFORM_CLASSES_ROOT_DIR)/sun/nio/fs/SolarisConstants-$(PLATFORM)-$(ARCH).java $@
>> Should be written as:
>> 884 $(SFS_GEN)/SolarisConstants.java: $(NIO_PLATFORM_CLASSES_ROOT_DIR)/sun/nio/fs/SolarisConstants-$(PLATFORM)-$(ARCH).java
>> 885         $(prep-target)
>> 886         $(CP) $< $@
>> -kto
>> On Jun 16, 2011, at 10:03 PM, David Holmes wrote:
>>> http://cr.openjdk.java.net/~dholmes/7039182/webrev/
>>> 
>>> This will be pushed through the TL jdk repo but Alan suggested getting build-dev to review (in addition to himself).
>>> 
>>> This isn't a public bug so I'll describe the issue.
>>> 
>>> When the NIO libs are built there are a few files that contain constants that represent platform specific I/O constants found in various C header files. Normally the build process compiles and runs a small C program which will generate the .java file for that platform.
>>> 
>>> When I integrated the basic support for cross-compilation I modified this process to use the host C compiler not the cross-compiler for the target, as we couldn't execute the resulting C program. That wasn't the correct thing to do because it means we generate values for the build platform not the target platform. Luckily these values are mostly the same on the Linux platforms we care about, but not all the same (hence this bug report where a read system call returned EINVAL because we thought we were passing O_NOFOLLOW but in fact passed O_DIRECT).
>>> 
>>> The simplest fix is to not try to generate a file when cross-compiling but allow the developer to specify where these files can be found. This is done using the NIO_PLATFORM_CLASSES_ROOT_DIR variable which is expected to be the "root" directory for where classes can be found and the directories under that are expected to follow the package hierarchy for the files, so, for example we will look for:
>>> 
>>> $(NIO_PLATFORM_CLASSES_ROOT_DIR)/sun/nio/ch/SocketOptionRegistry-$(PLATFORM)-$(ARCH).java
>>> 
>>> the platform and arch are used in the filename as we don't have platform/arch directories in the JDK repo.
>>> 
>>> In addition I reverted the original change to use the host C compiler as this allows you to specifically build the generator program using the cross-compiler (which will get the right values) then copy it across to the target system and run it to generate the file.
>>> 
>>> For SE-Embedded we need to set NIO_PLATFORM_CLASSES_ROOT_DIR to point into the "closed" platform sources.
>>> 
>>> Thanks,
>>> David Holmes