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