Request for review: 7039182 NIO platform specific files

[David Holmes]

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
>