Re: _BOOTDIR1 on MS Windows platform
This sanity check would be a "nice to have" thing, but it it can't
be done in a simple way I'm not sure I want to see a bunch of convoluted
logic added, we have too much of that already :^(
And it does go beyond your intended change. Maybe a separate bug for
another time, like a "sanity warnings on common build performance situations"?
On Solaris/Linux I have never seen a performance issue with reading
networked files, maybe a reliability issue when machines go down.
But writing to a network drive is more expensive, so if OUTPUTDIR
was a network drive, that might justify some kind of warning for all
platforms.
On the otherhand, I'm not sure I want to drive people too crazy with
warnings like this... I'd like to hear some more opinions on this.
-kto
Anthony Petrov wrote:
Jon, Kelly,
Then what about the default builds on Linux/Solaris that do use the
/java share and do not issue any warning message? I agree that these
builds are generally much faster than on Windows, but still. Besides, as
I mentioned before, on my local systems the /java directory and the J:
disk are local directories that just get occasionally synced. So the
warning would be meaningless for such configurations...
--
best regards,
Anthony
On 4/23/2009 10:54 PM Kelly O'Hair wrote:
Adding a sanity check warning about J:/ usage would be a nice addition
to this change.
-kto
Jonathan Gibbons wrote:
Kelly,
Perhaps "make sanity" on Windows could give a warning about the use
of network paths, if such is detected.
-- Jon
Kelly O'Hair wrote:
Sorry I'm so slow in responding to this...
The primary reason for the special case on Windows is the unreliability
and slowness of the network connections.
Builds using a local jdk vs. a J:/ mapped can be 5 hours long when
they might normally be 1hr or less. These just come from reports I
have gotten over the years, and it's really depends on the Windows
machine, the network, etc.
Bottom line, builds are always faster and more reliable when all
components
are stored on local disk, and this is particularly true on Windows.
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.
---
I have been recently working on the JavaFX build dependency issues
and although it's more ant based, some of the techniques could apply
to making OpenJDK builds easier. Unfortunately, there is only 24hrs
in a day. :^{
-kto
Anthony Petrov wrote:
Hello,
Back in 2007 we already discussed this issue with Kelly, but
transitioning to Mercurial just stopped the work. So, I would like
to revive this now.
Here's a part of the output generated by `grep -r BOOTDIR make/*`:
make/common/shared/Defs-solaris.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-solaris.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR1
=$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-linux.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-linux.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
One can notice that the _BOOTDIR1 is defined differently on MS
Windows platform. I would like to propose a change so that its
value would be the same as on other platforms. The SLASH_JAVA on MS
Windows equals to the J: drive. So one could setup the same
directory tree as on Linux/Solaris, use the subst command to make
the directory the J: drive, and be able to build the jdk w/o
specifying the ALT_BOOTDIR variable manually.
Is there any objection to removing the
$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION) default path?
--
best regards,
Anthony
Re: _BOOTDIR1 on MS Windows platform
Anthony,
On pretty much any system you can tell if a drive is local or not,
albeit in a system specific way.
-- Jon
Anthony Petrov wrote:
Jon, Kelly,
Then what about the default builds on Linux/Solaris that do use the
/java share and do not issue any warning message? I agree that these
builds are generally much faster than on Windows, but still. Besides,
as I mentioned before, on my local systems the /java directory and the
J: disk are local directories that just get occasionally synced. So
the warning would be meaningless for such configurations...
--
best regards,
Anthony
On 4/23/2009 10:54 PM Kelly O'Hair wrote:
Adding a sanity check warning about J:/ usage would be a nice addition
to this change.
-kto
Jonathan Gibbons wrote:
Kelly,
Perhaps "make sanity" on Windows could give a warning about the use
of network paths, if such is detected.
-- Jon
Kelly O'Hair wrote:
Sorry I'm so slow in responding to this...
The primary reason for the special case on Windows is the
unreliability
and slowness of the network connections.
Builds using a local jdk vs. a J:/ mapped can be 5 hours long when
they might normally be 1hr or less. These just come from reports I
have gotten over the years, and it's really depends on the Windows
machine, the network, etc.
Bottom line, builds are always faster and more reliable when all
components
are stored on local disk, and this is particularly true on Windows.
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.
---
I have been recently working on the JavaFX build dependency issues
and although it's more ant based, some of the techniques could apply
to making OpenJDK builds easier. Unfortunately, there is only 24hrs
in a day. :^{
-kto
Anthony Petrov wrote:
Hello,
Back in 2007 we already discussed this issue with Kelly, but
transitioning to Mercurial just stopped the work. So, I would like
to revive this now.
Here's a part of the output generated by `grep -r BOOTDIR make/*`:
make/common/shared/Defs-solaris.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-solaris.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR1
=$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-linux.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-linux.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
One can notice that the _BOOTDIR1 is defined differently on MS
Windows platform. I would like to propose a change so that its
value would be the same as on other platforms. The SLASH_JAVA on
MS Windows equals to the J: drive. So one could setup the same
directory tree as on Linux/Solaris, use the subst command to make
the directory the J: drive, and be able to build the jdk w/o
specifying the ALT_BOOTDIR variable manually.
Is there any objection to removing the
$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION) default path?
--
best regards,
Anthony
Re: _BOOTDIR1 on MS Windows platform
Jon, Kelly,
Then what about the default builds on Linux/Solaris that do use the
/java share and do not issue any warning message? I agree that these
builds are generally much faster than on Windows, but still. Besides, as
I mentioned before, on my local systems the /java directory and the J:
disk are local directories that just get occasionally synced. So the
warning would be meaningless for such configurations...
--
best regards,
Anthony
On 4/23/2009 10:54 PM Kelly O'Hair wrote:
Adding a sanity check warning about J:/ usage would be a nice addition
to this change.
-kto
Jonathan Gibbons wrote:
Kelly,
Perhaps "make sanity" on Windows could give a warning about the use
of network paths, if such is detected.
-- Jon
Kelly O'Hair wrote:
Sorry I'm so slow in responding to this...
The primary reason for the special case on Windows is the unreliability
and slowness of the network connections.
Builds using a local jdk vs. a J:/ mapped can be 5 hours long when
they might normally be 1hr or less. These just come from reports I
have gotten over the years, and it's really depends on the Windows
machine, the network, etc.
Bottom line, builds are always faster and more reliable when all
components
are stored on local disk, and this is particularly true on Windows.
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.
---
I have been recently working on the JavaFX build dependency issues
and although it's more ant based, some of the techniques could apply
to making OpenJDK builds easier. Unfortunately, there is only 24hrs
in a day. :^{
-kto
Anthony Petrov wrote:
Hello,
Back in 2007 we already discussed this issue with Kelly, but
transitioning to Mercurial just stopped the work. So, I would like
to revive this now.
Here's a part of the output generated by `grep -r BOOTDIR make/*`:
make/common/shared/Defs-solaris.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-solaris.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR1
=$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-linux.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-linux.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
One can notice that the _BOOTDIR1 is defined differently on MS
Windows platform. I would like to propose a change so that its value
would be the same as on other platforms. The SLASH_JAVA on MS
Windows equals to the J: drive. So one could setup the same
directory tree as on Linux/Solaris, use the subst command to make
the directory the J: drive, and be able to build the jdk w/o
specifying the ALT_BOOTDIR variable manually.
Is there any objection to removing the
$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION) default path?
--
best regards,
Anthony
Re: _BOOTDIR1 on MS Windows platform
On 4/23/2009 10:15 PM Kelly O'Hair wrote:
The primary reason for the special case on Windows is the unreliability
and slowness of the network connections.
Builds using a local jdk vs. a J:/ mapped can be 5 hours long when
they might normally be 1hr or less. These just come from reports I
have gotten over the years, and it's really depends on the Windows
machine, the network, etc.
Bottom line, builds are always faster and more reliable when all components
are stored on local disk, and this is particularly true on Windows.
I totally agree with that. That's why my J: disk is NOT a network share,
but a local directory that is mapped on the J: drive using the 'subst'
command. This directory, however, gets synced with the real /java
network share from time to time. So not setting the ALT_BOOTDIR does not
slows down my builds in any way. What's more, it enables me to build by
just issuing the make command, w/o setting ANY ALT_ variables in most cases.
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.
I believe most people that might possibly be affected by this change
reside on this mailing list. Who isn't - they probably either use the
ALT_BOOTDIR, or, in the worst case, will be able to easily identify the
problem since the reported error will include the /NO_BOOTDIR/ path to
the javac compiler.
--
best regards,
Anthony
---
I have been recently working on the JavaFX build dependency issues
and although it's more ant based, some of the techniques could apply
to making OpenJDK builds easier. Unfortunately, there is only 24hrs
in a day. :^{
-kto
Anthony Petrov wrote:
Hello,
Back in 2007 we already discussed this issue with Kelly, but
transitioning to Mercurial just stopped the work. So, I would like to
revive this now.
Here's a part of the output generated by `grep -r BOOTDIR make/*`:
make/common/shared/Defs-solaris.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-solaris.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR1
=$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-linux.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-linux.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
One can notice that the _BOOTDIR1 is defined differently on MS Windows
platform. I would like to propose a change so that its value would be
the same as on other platforms. The SLASH_JAVA on MS Windows equals to
the J: drive. So one could setup the same directory tree as on
Linux/Solaris, use the subst command to make the directory the J:
drive, and be able to build the jdk w/o specifying the ALT_BOOTDIR
variable manually.
Is there any objection to removing the
$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION) default path?
--
best regards,
Anthony
Re: _BOOTDIR1 on MS Windows platform
Adding a sanity check warning about J:/ usage would be a nice addition
to this change.
-kto
Jonathan Gibbons wrote:
Kelly,
Perhaps "make sanity" on Windows could give a warning about the use
of network paths, if such is detected.
-- Jon
Kelly O'Hair wrote:
Sorry I'm so slow in responding to this...
The primary reason for the special case on Windows is the unreliability
and slowness of the network connections.
Builds using a local jdk vs. a J:/ mapped can be 5 hours long when
they might normally be 1hr or less. These just come from reports I
have gotten over the years, and it's really depends on the Windows
machine, the network, etc.
Bottom line, builds are always faster and more reliable when all
components
are stored on local disk, and this is particularly true on Windows.
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.
---
I have been recently working on the JavaFX build dependency issues
and although it's more ant based, some of the techniques could apply
to making OpenJDK builds easier. Unfortunately, there is only 24hrs
in a day. :^{
-kto
Anthony Petrov wrote:
Hello,
Back in 2007 we already discussed this issue with Kelly, but
transitioning to Mercurial just stopped the work. So, I would like to
revive this now.
Here's a part of the output generated by `grep -r BOOTDIR make/*`:
make/common/shared/Defs-solaris.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-solaris.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR1
=$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-linux.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-linux.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
One can notice that the _BOOTDIR1 is defined differently on MS
Windows platform. I would like to propose a change so that its value
would be the same as on other platforms. The SLASH_JAVA on MS Windows
equals to the J: drive. So one could setup the same directory tree as
on Linux/Solaris, use the subst command to make the directory the J:
drive, and be able to build the jdk w/o specifying the ALT_BOOTDIR
variable manually.
Is there any objection to removing the
$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION) default path?
--
best regards,
Anthony
Re: _BOOTDIR1 on MS Windows platform
Kelly,
Perhaps "make sanity" on Windows could give a warning about the use
of network paths, if such is detected.
-- Jon
Kelly O'Hair wrote:
Sorry I'm so slow in responding to this...
The primary reason for the special case on Windows is the unreliability
and slowness of the network connections.
Builds using a local jdk vs. a J:/ mapped can be 5 hours long when
they might normally be 1hr or less. These just come from reports I
have gotten over the years, and it's really depends on the Windows
machine, the network, etc.
Bottom line, builds are always faster and more reliable when all
components
are stored on local disk, and this is particularly true on Windows.
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.
---
I have been recently working on the JavaFX build dependency issues
and although it's more ant based, some of the techniques could apply
to making OpenJDK builds easier. Unfortunately, there is only 24hrs
in a day. :^{
-kto
Anthony Petrov wrote:
Hello,
Back in 2007 we already discussed this issue with Kelly, but
transitioning to Mercurial just stopped the work. So, I would like to
revive this now.
Here's a part of the output generated by `grep -r BOOTDIR make/*`:
make/common/shared/Defs-solaris.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-solaris.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR1
=$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-linux.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-linux.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
One can notice that the _BOOTDIR1 is defined differently on MS
Windows platform. I would like to propose a change so that its value
would be the same as on other platforms. The SLASH_JAVA on MS Windows
equals to the J: drive. So one could setup the same directory tree as
on Linux/Solaris, use the subst command to make the directory the J:
drive, and be able to build the jdk w/o specifying the ALT_BOOTDIR
variable manually.
Is there any objection to removing the
$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION) default path?
--
best regards,
Anthony
Re: _BOOTDIR1 on MS Windows platform
Sorry I'm so slow in responding to this...
The primary reason for the special case on Windows is the unreliability
and slowness of the network connections.
Builds using a local jdk vs. a J:/ mapped can be 5 hours long when
they might normally be 1hr or less. These just come from reports I
have gotten over the years, and it's really depends on the Windows
machine, the network, etc.
Bottom line, builds are always faster and more reliable when all components
are stored on local disk, and this is particularly true on Windows.
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.
---
I have been recently working on the JavaFX build dependency issues
and although it's more ant based, some of the techniques could apply
to making OpenJDK builds easier. Unfortunately, there is only 24hrs
in a day. :^{
-kto
Anthony Petrov wrote:
Hello,
Back in 2007 we already discussed this issue with Kelly, but
transitioning to Mercurial just stopped the work. So, I would like to
revive this now.
Here's a part of the output generated by `grep -r BOOTDIR make/*`:
make/common/shared/Defs-solaris.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-solaris.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR1
=$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-linux.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-linux.gmk: _BOOTDIR2
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
One can notice that the _BOOTDIR1 is defined differently on MS Windows
platform. I would like to propose a change so that its value would be
the same as on other platforms. The SLASH_JAVA on MS Windows equals to
the J: drive. So one could setup the same directory tree as on
Linux/Solaris, use the subst command to make the directory the J: drive,
and be able to build the jdk w/o specifying the ALT_BOOTDIR variable
manually.
Is there any objection to removing the
$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION) default path?
--
best regards,
Anthony
