Review request: 6833444 (_BOOTDIR1/_BOOTDIR2 on MS Windows should be consistent with other platforms)

[Anthony Petrov]

On 4/23/2009 10:31 PM Xiomara.Jayasena at Sun.COM wrote:
> We do set ALT_BOOTDIR all the time.
> 
>  From Kelly:
>> 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. 
> 
> It's OK with me, if you remove c:/jdk ...
Great to hear that! Thanks!

--
best regards,
Anthony

> 
> Thanks,
> -Xiomara
> 
> 
> On 04/23/09 09:31, Anthony Petrov wrote:
>> Hi Xiomara,
>>
>> Thank you for the comments!
>>
>> On 4/23/2009 6:27 PM Xiomara Jayasena wrote:
>>> Release Engineering uses c:\jdk ... when building on windows.  We 
>>> will still need that.
>> Ups. I'm sorry about that, I really didn't know you use this path. 
>> This was the reason I initiated the discussion on the build-dev@ 
>> yesterday. Since I didn't receive any feedback, I assumed nobody cares 
>> about c:\jdk.
>>
>>> I am understanding that, that is being removed?
>>>
>>> -  _BOOTDIR1  =$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
>>> +  _BOOTDIR1  =$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archiv
>> Yes, this is correct.
>> Well, then perhaps I'll go and add the _BOOTDIR3 then. So, on Windows 
>> we will have three options: c:\jdk, c:\program files\java, and finally 
>> the standard j: approach introduced with the fix. Does it sound good?
>>
>>> RE tries to localized all the software we use in the local build system.
>> So do I on my local Windows build machine. And it seems that 
>> maintaining a local copy of the standard directory tree (/java --> j:) 
>> is *way* simpler than inventing something new. I just sync my local 
>> directory with the /java network share, and use the 'subst' command to 
>> make the J: disk out of the directory. With this configuration all the 
>> default options in the makefiles make sense, and I don't need to 
>> define any additional environment variables prior to running make 
>> (well, excluding the vsvars32.bat, of course, but that's another story).
>>
>> PS. I moved the discussion to the build-dev@, since it is basically 
>> the fix reviewing.
>>
>> -- 
>> best regards,
>> Anthony
>