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
