_BOOTDIR1 on MS Windows platform

[Anthony Petrov]

On 4/23/2009 10:15 PM Kelly O'Hair wrote:
> The primary reason for the special case on Windows is the unreliability
> and slowness of the network connections.
> Builds using a local jdk vs. a J:/ mapped can be 5 hours long when
> they might normally be 1hr or less. These just come from reports I
> have gotten over the years, and it's really depends on the Windows
> machine, the network, etc.
> 
> Bottom line, builds are always faster and more reliable when all components
> are stored on local disk, and this is particularly true on Windows.
I totally agree with that. That's why my J: disk is NOT a network share, 
but a local directory that is mapped on the J: drive using the 'subst' 
command. This directory, however, gets synced with the real /java 
network share from time to time. So not setting the ALT_BOOTDIR does not 
slows down my builds in any way. What's more, it enables me to build by 
just issuing the make command, w/o setting ANY ALT_ variables in most cases.

> Having said all that, I ALWAYS set ALT_BOOTDIR to my local copy
> (and ALT_JDK_IMPORT_PATH too). So I probably would not be impacted
> by this change, but I bet quite a few people rely on this c:/jdk1.6.0
> default. With enough warning you might be able to change this.
I believe most people that might possibly be affected by this change 
reside on this mailing list. Who isn't - they probably either use the 
ALT_BOOTDIR, or, in the worst case, will be able to easily identify the 
problem since the reported error will include the /NO_BOOTDIR/ path to 
the javac compiler.

--
best regards,
Anthony


> 
> ---
> 
> I have been recently working on the JavaFX build dependency issues
> and although it's more ant based, some of the techniques could apply
> to making OpenJDK builds easier. Unfortunately, there is only 24hrs
> in a day. :^{
> 
> -kto
> 
> 
> Anthony Petrov wrote:
>> Hello,
>>
>> Back in 2007 we already discussed this issue with Kelly, but 
>> transitioning to Mercurial just stopped the work. So, I would like to 
>> revive this now.
>>
>> Here's a part of the output generated by `grep -r BOOTDIR make/*`:
>>
>>> make/common/shared/Defs-solaris.gmk:  _BOOTDIR1  
>>> =$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH) 
>>>
>>> make/common/shared/Defs-solaris.gmk:  _BOOTDIR2  
>>> =$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
>>> make/common/shared/Defs-windows.gmk:  _BOOTDIR1  
>>> =$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
>>> make/common/shared/Defs-windows.gmk:  _BOOTDIR2  
>>> =$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
>>> make/common/shared/Defs-linux.gmk:  _BOOTDIR1  
>>> =$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH) 
>>>
>>> make/common/shared/Defs-linux.gmk:  _BOOTDIR2  
>>> =$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
>>
>> One can notice that the _BOOTDIR1 is defined differently on MS Windows 
>> platform. I would like to propose a change so that its value would be 
>> the same as on other platforms. The SLASH_JAVA on MS Windows equals to 
>> the J: drive. So one could setup the same directory tree as on 
>> Linux/Solaris, use the subst command to make the directory the J: 
>> drive, and be able to build the jdk w/o specifying the ALT_BOOTDIR 
>> variable manually.
>>
>> Is there any objection to removing the 
>> $(_system_drive)/jdk$(PREVIOUS_JDK_VERSION) default path?
>>
>> -- 
>> best regards,
>> Anthony