Review request: 6833444 (_BOOTDIR1/_BOOTDIR2 on MS Windows should be consistent with other platforms)
Anthony.Petrov at Sun.COM
Thu Apr 23 12:25:42 PDT 2009
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!
> 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,
More information about the build-dev