_BOOTDIR1 on MS Windows platform

[Anthony Petrov]

Jon, Kelly,

Then what about the default builds on Linux/Solaris that do use the 
/java share and do not issue any warning message? I agree that these 
builds are generally much faster than on Windows, but still. Besides, as 
I mentioned before, on my local systems the /java directory and the J: 
disk are local  directories that just get occasionally synced. So the 
warning would be meaningless for such configurations...

--
best regards,
Anthony

On 4/23/2009 10:54 PM Kelly O'Hair wrote:
> Adding a sanity check warning about J:/ usage would be a nice addition
> to this change.
> 
> -kto
> 
> Jonathan Gibbons wrote:
>> Kelly,
>>
>> Perhaps "make sanity" on Windows could give a warning about the use
>> of network paths, if such is detected.
>>
>> -- Jon
>>
>>
>> Kelly O'Hair wrote:
>>> Sorry I'm so slow in responding to this...
>>>
>>> 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.
>>>
>>> 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 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
>>