Re: Question about BUILD_HEADLESS and HEADLESS

2012-02-15 Thread Michael McMahon
The stub library is headless/libmawt.so*. Right? It's being built on Mac 
OS as well, but currently being
put in a different location to the normal one. It also seems like it is 
not being used
because if you rename or delete it, there isn't any change in behavior, 
which sounds like a bug.


So, what exactly is the function of the stub library? Is it to allow 
some functions of awt to work

that don't require a real display?

In any case, I don't see why Mac should be different from Solaris or 
Linux in this respect.


- Michael.

* In 8 it has a different name, but it'll be built on Mac as well in 8.

On 14/02/12 17:27, Phil Race wrote:

On windows headless is simply a state.
But Solaris/Linux have true headless builds where there are headless 
(stub) versions of UI libraries.
And I think that headless is a valid JCK mode .. you can pass JCK in 
headless
on platforms that don't support UI. But I'd check the JCK guys on that 
one,

don't take my word for it.

-phk.

On 2/14/2012 6:49 AM, Michael McMahon wrote:

On 14/02/12 13:47, Fredrik Öhrström wrote:

Is the use of HEADLESS in gcc.make (linux and bsd) an archaeological
remnant and should be removed? (No source in the hotspot repo looks a
the HEADLESS define.)

Is there any reason to not build a headless version of awt? (ie modify
BUILD_HEADLESS to not be defined.)
It seeems like headless is not currently built on bsd/macosx/windows,
but it is built on solaris and linux?

//Fredrik

Fredrik,

It's being built on macosx as well.

- Michael.






Re: Question about BUILD_HEADLESS and HEADLESS

2012-02-15 Thread Fredrik Öhrström
- david.hol...@oracle.com skrev:
 I'm not sure what you are asking. BUILD_HEADLESS is a JDK build flag.
 As you say it is set true in the linux and solaris Def-os.gmk files,
 and AFAICS it is only used in one place in make/sun/headless/Makefile
 
 Note: BUILD_HEADLESS_ONLY is an unrelated option that was added to 
 support special SE Embedded builds on platforms with no X11 includes
 or libraries available at all.

Ok, the question concerns the api for configuring the build.

My personal opinion now, is that the build should always compile support for 
headless execution of the jdk. 

But you can disable the compilation of head support with 
./configure --disable-head 

This seems to be consistent with the actual usage of the old makefile variables 
according to the answers I got to this question.

//Fredrik


Re: Is anyone able to build on Win 7

2012-02-15 Thread Fredrik Öhrström
- kelly.oh...@oracle.com skrev:

 So I'm with you on the stat() theory, makes a great deal of sense.

The stat theory is very interesting, but it is unclear to me if it explains all 
of the problem.

I setup a quadruple boot x86_64 machine with 4GB of ram and 4 cores:
Winxp 32bit
Win7 64bit
Solaris 64bit
Ubuntu 64bit

And tested the build times on the different OS:es.

Ubuntu Fastest by far.

Solaris, slower, but this is only because of bad CC performance.

Winxp, even slower but still ok.

Win7, ridiculously slow. The configure script prints one line per second!

Clearly, just running a bash script in cygwin/win7/64bit is problematic.
If we get 10% speedup from dash, then that is not going to help because
the slowdown is a factor 10.

Could someone try out the difference between a 32bit win7 clean install and a 
64 bit win7 clean install when running the latest cygwin and just the 
build-infra/jdk8/common/autoconf/configure script?

(My patience for installing many OSes into the same box, just ran out. And 
virtualization
testing can give a hint, but cannot be entirely trusted.)

//Fredrik


Re: Review for 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable

2012-02-15 Thread Erik Joelsson

New webrev:
http://cr.openjdk.java.net/~erikj/7141244/webrev.04/
175 lines changed: 87 ins; 29 del; 59 mod; 3970 unchg

I discovered that the -include $(SPEC) line needed to be added to the 
make/{bsd,solaris,linux}/makefiles/buildtree.make files. Otherwise the 
hotspot build won't respect setting OPENJDK=true in the spec.


It seems the windows build isn't respecting the OPENJDK variable today 
so I won't bother fixing that.


/Erik

On 2012-02-07 17:30, Erik Joelsson wrote:
http://cr.openjdk.java.net/~erikj/7141244/webrev.00/ 
http://cr.openjdk.java.net/%7Eerikj/7141244/webrev.00/

178 lines changed: 115 ins; 7 del; 56 mod; 4625 unchg

7141244: build-infra merge: Include $(SPEC) in makefiles and make 
variables overridable


The build-infra project is starting to move into jdk8. For the hotspot 
build to stay compatible with the changes, key hotspot makefiles need 
to add an optional include statement:



-include $(SPEC)

In the new build system, the spec file is generated by configure and 
contains the configuration for the build. Only a handfull of files 
need to add this line.


In addition to including the spec file, some variables need to be 
changed to only be set conditionally so that a value from the spec 
file takes precedence. These are: CC, CXX, CPP, AS, MCS, STRIP, NM, 
NAWK (and for windows RC and MT). The hotspot makefiles should check 
each variable if it's already set or if it has a gnumake default value.


These changes have been verified to work for hotspot-rt. Jdk7u will be 
verified as well before pushing.


/Erik



Re: building part of jdk 8

2012-02-15 Thread Kelly O'Hair
The debug (obj_g/), fastdebug (obj_gO/), and product (obj/) directories keep 
the different .o or .obj files
separate, since there is no guarantee that these can be mixed together and work.
All compilations for a library need to be the same kind of compilation.

-kto

On Feb 14, 2012, at 7:35 PM, Pete Brunet wrote:

 I don't know if this is a problem but it's something I noticed.  When I
 do the full fastdebug_build build there are two directories under
 C:\OpenJDK\jdk8\build\windows-i586-fastdebug\tmp\sun\sun.awt\awt, i.e.
 CClassHeaders and Obj_gO.  When I then do the partial build of awt
 (described in the history below) a new directory, obj, is added and
 populated.
 
 On 2/13/12 3:13 PM, Kelly O'Hair wrote:
 On Feb 13, 2012, at 12:12 PM, Pete Brunet wrote:
 
 On 2/13/12 1:35 PM, Kelly O'Hair wrote:
 Just a few comments below...
 
 On Feb 13, 2012, at 9:08 AM, Pete Brunet wrote:
 
 This worked for me today for building just awt:
 
 This is in my bat file.  The first two sets are what resolved my issue.
 set ALT_OUTPUTDIR=c:/OpenJDK/jdk8/build/windows-i586-fastdebug
 set
 ALT_JDK_IMPORT_PATH=c:/OpenJDK/jdk8/build/windows-i586-fastdebug/j2sdk-image
 The above two settings make no sense to me.
 
 ALT_OUTPUTDIR is supposed to point at the directory where you want the 
 build results to go.
 One of the directories created is the j2sdk-image. This is a huge disk 
 write area.
 I think I needed this to make my partial build use the same directory as
 my fastdebug_build full build.
 Understood. That's a perfectly valid reason.
 
 ALT_JDK_IMPORT_PATH is something you set when you are doing partial 
 builds, e.g.
 not building hotspot. It needs to point at some place that is pretty 
 golden and steady, for
 a place to get parts of the jdk image that you are not building.
 You have it set to the same place you are building. :^(  That seems fishy 
 to me.
 I would have done a full build, moved or copied j2sdk-image to some place 
 safe, and
 had ALT_JDK_IMPORT_PATH refer to that copy, where it would be safe from 
 destruction
 during the build.
 I only build parts of awt and swing so maybe I've been lucky.  In any
 event I made that change.
 set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02
 The official boot jdk for jdk8 is actually the first shipping jdk7, 
 although 7u2 should work,
 our release engineering and automated build systems use jdk7 fcs.
 
 set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include
 set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010
 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1
 set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin
 Not sure why ALT_MSDEVTOOLS_PATH is needed. Did you find this necessary 
 for some reason?
 
 set CLASSPATH=
 set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;
 set CYGWIN=nodosfilewarning
 cd c:\Users\Pete\cygwin\bin
 bash --login -i
 This bash command will add /usr/bin to the PATH, and convert PATH to the 
 CYGWIN world.
 Do I need to change something?
 No you are perfectly fine.  I was just commenting that the PATH setting has 
 changed.
 I always keep track of when PATH changes.
 
 Then at the cygwin command line:
 eval `bin/vsvars.sh -v10 -32`
 Perfect. That adjusts PATH, LIB, INCLUDE, etc, all for the Visual Studio 
 compiler.
 
 cd /cygdrive/c/OpenJDK/jdk8/jdk/make/sun/awt/
 make ARCH_DATA_MODEL=32 21 | tee build.log
 Yup.
 
 Note: I suspect I don't need wbem in my path; I'll remove it the next
 time I do a build.
 I've never been sure about Wbem needing to be in the system path. Let me 
 know what you find out.
 Rebuilding after tweaking awt_Component.cpp worked fine without this. 
 I'll report back at some other time after doing a full rebuild.
 http://www.pcreview.co.uk/forums/do-need-wbem-path-statement-t2330116.html
 
 My tendency is to leave Wbem in PATH. Not sure we need it, but why vary the 
 standard Windows
 PATH and ask for trouble? ;^)
 
 -kto
 
 
 So this is Windows 7 right?
 Is it Windows 7 X64 or X86? (32 or 64 bit OS)
 64 bit Windows 7
 Do you have any anti-virus software installed, and any special settings?
 I have Norton 360 and for a full build I disable auto-protect.  I don't
 bother disabling that for a partial build.
 Is this the latest CYGWIN? (what does uname -a say?)
 1.7.0 (I dropped back from using 1.7.9 and so far this has been working,
 but I haven't done enough full builds yet to be sure.)
 
 Pete
 There have been reports of problems with Windows 7 building, possibly 
 involving CYGWIN and McAfee
 colliding somehow. Just curious.
 
 -kto
 
 Pete
 
 On 2/2/12 2:19 PM, Pete Brunet wrote:
 On 2/1/12 10:54 PM, Pete Brunet wrote:
 On 1/23/12 9:39 AM, Pete Brunet wrote:
 In the past I was able to build part of jdk 8 but that is not currently
 working although I am able to do a full 32 bit build.  I've recently
 moved from XP to W7 so my environment might not be set up quite right
 yet.  Here's what I do...
 
 // These are done in a bat file before I do any makes
 set 

Re: building part of jdk 8

2012-02-15 Thread Pete Brunet
Thanks Kelly, That's interesting.  That might provide a hint regarding a
problem I am working on.  When I do a full fastdebug_build build with my
patch applied I get a hang when exiting the app, but when I do a
subsequent partial build (with the side effect of using obj instead of
obj_gO) there is no problem.

What do I have to change in the following partial build invocation to
compile with fastdebug (and use the fastdebug obj_gO directory) or to
compile with debug (and use the debug obj_g directory)?

eval `bin/vsvars.sh -v10 -32`
cd /cygdrive/c/OpenJDK/jdk8/jdk/make/sun/awt/
make ARCH_DATA_MODEL=32 21 | tee build.log

As a reminder, this is what I do before invoking cywin:

set ALT_OUTPUTDIR=c:/OpenJDK/jdk8/build/windows-i586-fastdebug
set ALT_JDK_IMPORT_PATH=c:/OpenJDK/jdk8/build/j2sdk-image
set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02
set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include
set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010
set ANT_HOME=C:/Progra~2/apache-ant-1.7.1
set CLASSPATH=
set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;
set CYGWIN=nodosfilewarning

And if anyone has an idea why using obj_gO results in a hang on exit but
using obj doesn't that would be helpful.  Maybe when building just awt
there is a mismatch between the awt obj files and the rest of the obj
files that make up awt.dll.

Or maybe my full build needs to be a product build rather than a
fastdebug_build build (to ensure a match between my full and partial
builds).  Is that done by removing fastdebug_build when running make at
the top level?

Pete

On 2/15/12 10:37 AM, Kelly O'Hair wrote:
 The debug (obj_g/), fastdebug (obj_gO/), and product (obj/) directories keep 
 the different .o or .obj files
 separate, since there is no guarantee that these can be mixed together and 
 work.
 All compilations for a library need to be the same kind of compilation.

 -kto

 On Feb 14, 2012, at 7:35 PM, Pete Brunet wrote:

 I don't know if this is a problem but it's something I noticed.  When I
 do the full fastdebug_build build there are two directories under
 C:\OpenJDK\jdk8\build\windows-i586-fastdebug\tmp\sun\sun.awt\awt, i.e.
 CClassHeaders and Obj_gO.  When I then do the partial build of awt
 (described in the history below) a new directory, obj, is added and
 populated.

 On 2/13/12 3:13 PM, Kelly O'Hair wrote:
 On Feb 13, 2012, at 12:12 PM, Pete Brunet wrote:

 On 2/13/12 1:35 PM, Kelly O'Hair wrote:
 Just a few comments below...

 On Feb 13, 2012, at 9:08 AM, Pete Brunet wrote:

 This worked for me today for building just awt:

 This is in my bat file.  The first two sets are what resolved my issue.
 set ALT_OUTPUTDIR=c:/OpenJDK/jdk8/build/windows-i586-fastdebug
 set
 ALT_JDK_IMPORT_PATH=c:/OpenJDK/jdk8/build/windows-i586-fastdebug/j2sdk-image
 The above two settings make no sense to me.

 ALT_OUTPUTDIR is supposed to point at the directory where you want the 
 build results to go.
 One of the directories created is the j2sdk-image. This is a huge disk 
 write area.
 I think I needed this to make my partial build use the same directory as
 my fastdebug_build full build.
 Understood. That's a perfectly valid reason.

 ALT_JDK_IMPORT_PATH is something you set when you are doing partial 
 builds, e.g.
 not building hotspot. It needs to point at some place that is pretty 
 golden and steady, for
 a place to get parts of the jdk image that you are not building.
 You have it set to the same place you are building. :^(  That seems fishy 
 to me.
 I would have done a full build, moved or copied j2sdk-image to some place 
 safe, and
 had ALT_JDK_IMPORT_PATH refer to that copy, where it would be safe from 
 destruction
 during the build.
 I only build parts of awt and swing so maybe I've been lucky.  In any
 event I made that change.
 set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02
 The official boot jdk for jdk8 is actually the first shipping jdk7, 
 although 7u2 should work,
 our release engineering and automated build systems use jdk7 fcs.

 set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include
 set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010
 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1
 set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin
 Not sure why ALT_MSDEVTOOLS_PATH is needed. Did you find this necessary 
 for some reason?

 set CLASSPATH=
 set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;
 set CYGWIN=nodosfilewarning
 cd c:\Users\Pete\cygwin\bin
 bash --login -i
 This bash command will add /usr/bin to the PATH, and convert PATH to the 
 CYGWIN world.
 Do I need to change something?
 No you are perfectly fine.  I was just commenting that the PATH setting has 
 changed.
 I always keep track of when PATH changes.

 Then at the cygwin command line:
 eval `bin/vsvars.sh -v10 -32`
 Perfect. That adjusts PATH, LIB, INCLUDE, etc, all for the Visual Studio 
 compiler.

 cd /cygdrive/c/OpenJDK/jdk8/jdk/make/sun/awt/
 make 

Re: building part of jdk 8

2012-02-15 Thread Kelly O'Hair

On Feb 15, 2012, at 9:01 AM, Pete Brunet wrote:

 Thanks Kelly, That's interesting.  That might provide a hint regarding a
 problem I am working on.  When I do a full fastdebug_build build with my
 patch applied I get a hang when exiting the app, but when I do a
 subsequent partial build (with the side effect of using obj instead of
 obj_gO) there is no problem.
 
 What do I have to change in the following partial build invocation to
 compile with fastdebug (and use the fastdebug obj_gO directory) or to
 compile with debug (and use the debug obj_g directory)?
 
 eval `bin/vsvars.sh -v10 -32`
 cd /cygdrive/c/OpenJDK/jdk8/jdk/make/sun/awt/
 make ARCH_DATA_MODEL=32 21 | tee build.log
   ^ maybe use target fastdebug?

I think every Makefile that uses Library.gmk should have a fastdebug build 
target.

A fastdebug build is a combination of the variables VARIANT=DBG and 
FASTDEBUG=true
but it's been a long time since I looked at that. Proof is in the pudding. Good 
Luck.

-kto

 
 As a reminder, this is what I do before invoking cywin:
 
 set ALT_OUTPUTDIR=c:/OpenJDK/jdk8/build/windows-i586-fastdebug
 set ALT_JDK_IMPORT_PATH=c:/OpenJDK/jdk8/build/j2sdk-image
 set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02
 set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include
 set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010
 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1
 set CLASSPATH=
 set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;
 set CYGWIN=nodosfilewarning
 
 And if anyone has an idea why using obj_gO results in a hang on exit but
 using obj doesn't that would be helpful.  Maybe when building just awt
 there is a mismatch between the awt obj files and the rest of the obj
 files that make up awt.dll.
 
 Or maybe my full build needs to be a product build rather than a
 fastdebug_build build (to ensure a match between my full and partial
 builds).  Is that done by removing fastdebug_build when running make at
 the top level?
 
 Pete
 
 On 2/15/12 10:37 AM, Kelly O'Hair wrote:
 The debug (obj_g/), fastdebug (obj_gO/), and product (obj/) directories keep 
 the different .o or .obj files
 separate, since there is no guarantee that these can be mixed together and 
 work.
 All compilations for a library need to be the same kind of compilation.
 
 -kto
 
 On Feb 14, 2012, at 7:35 PM, Pete Brunet wrote:
 
 I don't know if this is a problem but it's something I noticed.  When I
 do the full fastdebug_build build there are two directories under
 C:\OpenJDK\jdk8\build\windows-i586-fastdebug\tmp\sun\sun.awt\awt, i.e.
 CClassHeaders and Obj_gO.  When I then do the partial build of awt
 (described in the history below) a new directory, obj, is added and
 populated.
 
 On 2/13/12 3:13 PM, Kelly O'Hair wrote:
 On Feb 13, 2012, at 12:12 PM, Pete Brunet wrote:
 
 On 2/13/12 1:35 PM, Kelly O'Hair wrote:
 Just a few comments below...
 
 On Feb 13, 2012, at 9:08 AM, Pete Brunet wrote:
 
 This worked for me today for building just awt:
 
 This is in my bat file.  The first two sets are what resolved my issue.
 set ALT_OUTPUTDIR=c:/OpenJDK/jdk8/build/windows-i586-fastdebug
 set
 ALT_JDK_IMPORT_PATH=c:/OpenJDK/jdk8/build/windows-i586-fastdebug/j2sdk-image
 The above two settings make no sense to me.
 
 ALT_OUTPUTDIR is supposed to point at the directory where you want the 
 build results to go.
 One of the directories created is the j2sdk-image. This is a huge disk 
 write area.
 I think I needed this to make my partial build use the same directory as
 my fastdebug_build full build.
 Understood. That's a perfectly valid reason.
 
 ALT_JDK_IMPORT_PATH is something you set when you are doing partial 
 builds, e.g.
 not building hotspot. It needs to point at some place that is pretty 
 golden and steady, for
 a place to get parts of the jdk image that you are not building.
 You have it set to the same place you are building. :^(  That seems 
 fishy to me.
 I would have done a full build, moved or copied j2sdk-image to some 
 place safe, and
 had ALT_JDK_IMPORT_PATH refer to that copy, where it would be safe from 
 destruction
 during the build.
 I only build parts of awt and swing so maybe I've been lucky.  In any
 event I made that change.
 set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02
 The official boot jdk for jdk8 is actually the first shipping jdk7, 
 although 7u2 should work,
 our release engineering and automated build systems use jdk7 fcs.
 
 set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include
 set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010
 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1
 set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin
 Not sure why ALT_MSDEVTOOLS_PATH is needed. Did you find this necessary 
 for some reason?
 
 set CLASSPATH=
 set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;
 set CYGWIN=nodosfilewarning
 cd c:\Users\Pete\cygwin\bin
 bash --login -i
 This bash command will add /usr/bin to the PATH, and 

hg: jdk8/build: Added tag jdk8-b25 for changeset 221a378e06a3

2012-02-15 Thread david . katleman
Changeset: 2accafff224a
Author:katleman
Date:  2012-02-09 12:55 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/rev/2accafff224a

Added tag jdk8-b25 for changeset 221a378e06a3

! .hgtags



hg: jdk8/build/corba: Added tag jdk8-b25 for changeset e45d6b406d5f

2012-02-15 Thread david . katleman
Changeset: 79f709a099f4
Author:katleman
Date:  2012-02-09 12:55 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/corba/rev/79f709a099f4

Added tag jdk8-b25 for changeset e45d6b406d5f

! .hgtags



hg: jdk8/build/hotspot: 18 new changesets

2012-02-15 Thread david . katleman
Changeset: aaceb8ddf2e2
Author:katleman
Date:  2012-02-09 12:55 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/aaceb8ddf2e2

Added tag jdk8-b25 for changeset 9ad8feb5afbd

! .hgtags

Changeset: 3c4621be5149
Author:amurillo
Date:  2012-02-06 12:18 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3c4621be5149

7143122: new hotspot build - hs23-b15
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 869be5c8882e
Author:phh
Date:  2012-02-03 17:21 -0500
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/869be5c8882e

7142586: Cannot build on Solaris 11 due to use of ia_nice
Summary: Delete the single use of ia_nice in os_solaris.cpp
Reviewed-by: kamg, kvn

! src/os/solaris/vm/os_solaris.cpp

Changeset: c77d473e71f7
Author:ohrstrom
Date:  2012-01-31 13:12 +0100
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c77d473e71f7

7132779: build-infra merge: Enable ccache to work for most developer builds.
Summary: When a build number is not specified, the JRE_RELEASE_VERSION define 
contains a date and timestamp. Thus ccache cannot cache the object files for 
longer than a minute since the define is passed to the compilation of all 
source files. This change passes JRE_RELEASE_VERSION only to vm_version.cpp and 
adds a function jre_release_version() to Abstract_VM_Version. This allows all 
other source files to be ccached.
Reviewed-by: ohair, rottenha
Contributed-by: fredrik.ohrst...@oracle.com

! make/bsd/makefiles/vm.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/vm.make
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/runtime/vm_version.hpp

Changeset: 719f7007c8e8
Author:erikj
Date:  2012-02-06 09:14 +0100
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/719f7007c8e8

7141242: build-infra merge: Rename CPP-CXX and LINK-LD
Summary: Cleaned up make variables for compilers and linker to consistently use 
CXX for C++ compiler, CC for C compiler and LD for linker.
Reviewed-by: dholmes, ohrstrom

! make/bsd/makefiles/adlc.make
! make/bsd/makefiles/dtrace.make
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/launcher.make
! make/bsd/makefiles/product.make
! make/bsd/makefiles/rules.make
! make/bsd/makefiles/sparcWorks.make
! make/bsd/makefiles/vm.make
! make/linux/makefiles/adlc.make
! make/linux/makefiles/gcc.make
! make/linux/makefiles/launcher.make
! make/linux/makefiles/product.make
! make/linux/makefiles/rules.make
! make/linux/makefiles/sparcWorks.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/adlc.make
! make/solaris/makefiles/dtrace.make
! make/solaris/makefiles/gcc.make
! make/solaris/makefiles/launcher.make
! make/solaris/makefiles/product.make
! make/solaris/makefiles/rules.make
! make/solaris/makefiles/saproc.make
! make/solaris/makefiles/sparcWorks.make
! make/solaris/makefiles/vm.make
! make/windows/build_vm_def.sh
! make/windows/get_msc_ver.sh
! make/windows/makefiles/adlc.make
! make/windows/makefiles/compile.make
! make/windows/makefiles/debug.make
! make/windows/makefiles/fastdebug.make
! make/windows/makefiles/launcher.make
! make/windows/makefiles/product.make
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/sa.make
! make/windows/makefiles/sanity.make
! make/windows/makefiles/shared.make
! make/windows/makefiles/vm.make

Changeset: ea677dbdd883
Author:fparain
Date:  2012-02-07 12:34 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ea677dbdd883

Merge


Changeset: 5e9fba4e8718
Author:kvn
Date:  2012-02-07 11:33 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5e9fba4e8718

7142167: MAC: _get_previous_fp broken on bsd with llvm-gcc
Summary: LLVM-GCC (__llvm__) should use the same _get_previous_fp 
implementation as __clang__ (as is the case for os::current_stack_pointer).
Reviewed-by: twisti, never, dcubed

! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp

Changeset: b9bc6cae88f2
Author:kvn
Date:  2012-02-07 16:33 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b9bc6cae88f2

7143491: G1 C2 CTW: assert(p2x-outcnt() == 2) failed: expects 2 users: Xor and 
URShift nodes
Summary: Adjust the assert and code in eliminate_card_mark() method for case 
when stored value is NULL.
Reviewed-by: iveresov, never

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/macro.cpp

Changeset: c742b0b47fe5
Author:roland
Date:  2012-02-08 09:52 +0100
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c742b0b47fe5

7119286: JSR292: SIGSEGV in JNIHandleBlock::release_block(JNIHandleBlock*, 
Thread*)+0x3c
Summary: unaligned stack in throw_NullPointerException_at_call_entry().
Reviewed-by: twisti, never, kvn

! src/cpu/x86/vm/stubGenerator_x86_64.cpp

Changeset: 2f985b6ce7ff
Author:jrose
Date:  2012-02-09 18:01 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2f985b6ce7ff

Merge


Changeset: 1ac084126285

hg: jdk8/build/jaxp: Added tag jdk8-b25 for changeset bb694c151fc7

2012-02-15 Thread david . katleman
Changeset: dbb7283c197b
Author:katleman
Date:  2012-02-09 12:55 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/jaxp/rev/dbb7283c197b

Added tag jdk8-b25 for changeset bb694c151fc7

! .hgtags



hg: jdk8/build/jdk: Added tag jdk8-b25 for changeset ec17fbe5b8fb

2012-02-15 Thread david . katleman
Changeset: 5aca406e87cb
Author:katleman
Date:  2012-02-09 12:56 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/jdk/rev/5aca406e87cb

Added tag jdk8-b25 for changeset ec17fbe5b8fb

! .hgtags



hg: jdk8/build/jaxws: Added tag jdk8-b25 for changeset b376d901e006

2012-02-15 Thread david . katleman
Changeset: 3518639eab6c
Author:katleman
Date:  2012-02-09 12:55 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/jaxws/rev/3518639eab6c

Added tag jdk8-b25 for changeset b376d901e006

! .hgtags



hg: jdk8/build/langtools: Added tag jdk8-b25 for changeset 520c30f85bb5

2012-02-15 Thread david . katleman
Changeset: b556aa8a99c3
Author:katleman
Date:  2012-02-09 12:56 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/langtools/rev/b556aa8a99c3

Added tag jdk8-b25 for changeset 520c30f85bb5

! .hgtags



Re: Review for 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable

2012-02-15 Thread David Holmes

On 16/02/2012 1:06 AM, Erik Joelsson wrote:

New webrev:
http://cr.openjdk.java.net/~erikj/7141244/webrev.04/
175 lines changed: 87 ins; 29 del; 59 mod; 3970 unchg

I discovered that the -include $(SPEC) line needed to be added to the
make/{bsd,solaris,linux}/makefiles/buildtree.make files. Otherwise the
hotspot build won't respect setting OPENJDK=true in the spec.


Is that the only change from version 3?

Have you verified you can do all three variants: openjdk, jdk, embedded jdk?


It seems the windows build isn't respecting the OPENJDK variable today
so I won't bother fixing that.


Can't comment on that.

David



/Erik

On 2012-02-07 17:30, Erik Joelsson wrote:

http://cr.openjdk.java.net/~erikj/7141244/webrev.00/
http://cr.openjdk.java.net/%7Eerikj/7141244/webrev.00/
178 lines changed: 115 ins; 7 del; 56 mod; 4625 unchg

7141244: build-infra merge: Include $(SPEC) in makefiles and make
variables overridable

The build-infra project is starting to move into jdk8. For the hotspot
build to stay compatible with the changes, key hotspot makefiles need
to add an optional include statement:


-include $(SPEC)

In the new build system, the spec file is generated by configure and
contains the configuration for the build. Only a handfull of files
need to add this line.

In addition to including the spec file, some variables need to be
changed to only be set conditionally so that a value from the spec
file takes precedence. These are: CC, CXX, CPP, AS, MCS, STRIP, NM,
NAWK (and for windows RC and MT). The hotspot makefiles should check
each variable if it's already set or if it has a gnumake default value.

These changes have been verified to work for hotspot-rt. Jdk7u will be
verified as well before pushing.

/Erik