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

Xiomara.Jayasena at Sun.COM Xiomara.Jayasena at Sun.COM
Thu Apr 23 18:31:40 UTC 2009


Hi Anthony,

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 ...

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




More information about the build-dev mailing list