Re: Where does 'make sanity' look for the ANT version?
Hi Stuart, Thanks for looking into that for me, I'll keep a note of the location of Sanity.gmk going forwards. I have managed to resolve the issue, it was a curious case where my 1.8.2 ANT install couldn't find $ALT_BOOTDIR//lib/tools.jar and therefore 'failed', the build then defaulted back to an ant under the langtools folder. I corrected a permissions problem on the tools.jar file and make sanity ran smoothly after that. Now having fun trying to find the exact Ubnutu package that contains the X11 headers the build needs, but that's a different story :-) Cheers, Martijn On 28 March 2012 02:22, Stuart Marks wrote: > Hi Martijn! > > One of my colleagues ran into this the other day. I don't know all the > details and the solution but I have a clue that might help you move forward. > > In make/common/shared/Sanity.gmk there are the lines, > >> _ANT_VER:=$(shell $(ANT) -version 2>&1 ) >> ANT_VER:=$(call GetVersion,"$(_ANT_VER)") > > > The GetVersion function (defined in Defs.gmk) extracts the version number > from the shell output using a regexp. Unfortunately there seem to be > circumstances -- not sure exactly what they are though -- when the shell > output includes a *java* version number, either in the output or in a path. > Clearly you're using Java 7 -- that is, JDK 1.7.0 -- and the GetVersion > regexp is happily picking this up thinking it's the ant version number. > > One path forward would be to investigate why "shell $(ANT) -version" is > returning some unexpected output and is possibly not even running ant at > all. > > I'll forward this to my colleague to see whether he has anything to add. > > s'marks > > > > On 3/26/12 3:55 AM, Martijn Verburg wrote: >> >> Hi all, >> >> So I'm building new VMs to try the various OpenJDK builds and have run >> across a pretty consistent problem using Lubuntu 11.10 (32-bit) with >> the detection of ANT. >> >> I have ANT 1.8.2 installed (Ant 1.7 is clearly removed) but 'make >> sanity' insists that the ANT version I have is 1.7.0. >> >> * My DEVTOOLS_PATH is pointing at /usr/bin which has the correct version >> of ANT >> * When I set ANT_HOME (export ANT_HOME=/usr/share/ant) before running >> 'make sanity' it doesn't appear to take hold (the output from make >> sanity shows ANT_HOME to be blank) >> >> I'm not sure where else it might be reading this from, does anyone >> where I should go spelunking to see where it makes this check? >> >> Cheers, >> Martijn
Re: Where does 'make sanity' look for the ANT version?
Hi Martijn! One of my colleagues ran into this the other day. I don't know all the details and the solution but I have a clue that might help you move forward. In make/common/shared/Sanity.gmk there are the lines, _ANT_VER:=$(shell $(ANT) -version 2>&1 ) ANT_VER:=$(call GetVersion,"$(_ANT_VER)") The GetVersion function (defined in Defs.gmk) extracts the version number from the shell output using a regexp. Unfortunately there seem to be circumstances -- not sure exactly what they are though -- when the shell output includes a *java* version number, either in the output or in a path. Clearly you're using Java 7 -- that is, JDK 1.7.0 -- and the GetVersion regexp is happily picking this up thinking it's the ant version number. One path forward would be to investigate why "shell $(ANT) -version" is returning some unexpected output and is possibly not even running ant at all. I'll forward this to my colleague to see whether he has anything to add. s'marks On 3/26/12 3:55 AM, Martijn Verburg wrote: Hi all, So I'm building new VMs to try the various OpenJDK builds and have run across a pretty consistent problem using Lubuntu 11.10 (32-bit) with the detection of ANT. I have ANT 1.8.2 installed (Ant 1.7 is clearly removed) but 'make sanity' insists that the ANT version I have is 1.7.0. * My DEVTOOLS_PATH is pointing at /usr/bin which has the correct version of ANT * When I set ANT_HOME (export ANT_HOME=/usr/share/ant) before running 'make sanity' it doesn't appear to take hold (the output from make sanity shows ANT_HOME to be blank) I'm not sure where else it might be reading this from, does anyone where I should go spelunking to see where it makes this check? Cheers, Martijn
Re: Review Request: Build-infra M1
2012-03-27 17:21, Michael McMahon skrev: Right. Configure doesn't need to be re-run, but presumably there is some build meta-information linking sources to target libraries etc. Say a new native library libfoo were to be added with associated C (and Java) sources. Where would this get added to the build system? New Java sources in the jdk need no special treatment (though if they are platform dependent you might have to be careful how they are added to the source tree, since it is a mess) and they are all compiled in a single javac invocation defined in CompileJavaClasses.gmk For native libraries, a new library is added as a macro call to SetupNativeCompilation in CompileNativeLibraries.gmk. All libraries are added to the variable BUILD_LIBRARIES and the target all depends on $(BUILD_LIBRARIES) The macro SetupNativeCompilation configures all dependencies between source files (and header files) to object files to the library. Enabling incremental builds. //Fredrik
Re: Review Request: Build-infra M1
On 27/03/12 16:04, Fredrik Öhrström wrote: 2012-03-27 16:39, Michael McMahon skrev: A few more things I'd like to understand are: 1) In what circumstances exactly would the configure script have to be re-run? You run configure once to setup a particular build configuration. After it is run, you only need to run make for the build configuration. Rerunning configure on an already setup build configuration is not recommended. If you want to tweak something (like different flags to compilers and such, just edit the generated spec.gmk file. 2) Can you give examples of the kind of build changes that would be needed :- - when a small'ish change is made (eg adding a couple of new source files, or renaming or removing them)? Adding/removing source files does not require a rerun of configure. - when a new component is added, with both Java and native sources in new source directories Adding an entire subdirectory of sources, more native source etc etc does not require a rerun of configure. Configure does not care about source code layout except where the repositories are. It knows how to find/download compilers/linkers/tools and create a spec.gmk file with all the necessary variables that encode this information. (For example: CC,JDK_TOPDIR,OUTPUT_ROOT,ARCH etc etc) Right. Configure doesn't need to be re-run, but presumably there is some build meta-information linking sources to target libraries etc. Say a new native library libfoo were to be added with associated C (and Java) sources. Where would this get added to the build system? - Michael
Re: Review Request: Build-infra M1
2012-03-27 16:39, Michael McMahon skrev: A few more things I'd like to understand are: 1) In what circumstances exactly would the configure script have to be re-run? You run configure once to setup a particular build configuration. After it is run, you only need to run make for the build configuration. Rerunning configure on an already setup build configuration is not recommended. If you want to tweak something (like different flags to compilers and such, just edit the generated spec.gmk file. 2) Can you give examples of the kind of build changes that would be needed :- - when a small'ish change is made (eg adding a couple of new source files, or renaming or removing them)? Adding/removing source files does not require a rerun of configure. - when a new component is added, with both Java and native sources in new source directories Adding an entire subdirectory of sources, more native source etc etc does not require a rerun of configure. Configure does not care about source code layout except where the repositories are. It knows how to find/download compilers/linkers/tools and create a spec.gmk file with all the necessary variables that encode this information. (For example: CC,JDK_TOPDIR,OUTPUT_ROOT,ARCH etc etc) //Fredrik
Re: Review Request: Build-infra M1
A few more things I'd like to understand are: 1) In what circumstances exactly would the configure script have to be re-run? 2) Can you give examples of the kind of build changes that would be needed :- - when a small'ish change is made (eg adding a couple of new source files, or renaming or removing them)? - when a new component is added, with both Java and native sources in new source directories Thanks, Michael
Re: Review Request: Build-infra M1
This isn't really an issue for the first push, more of a question as to how this will all look once the remaining make files has been converted. My question relates to jdk/makefiles/CompileJavaClasses.gmk and CompileNativeLibraries.gmk and how they will be maintained more longer term. Is the intention that over time that the references to AWT, JDWP, SCTP, and other specific areas will be moved elsewhere? -Alan
Re: Need JDK Reviewer for SIMPLE change! Free Karma!
Thank you sir, your Karma-points will be transferred to you within three Karma-bank days! Regards Nils Loodin On Mar 27, 2012, at 12:49 , David Holmes wrote: > On 27/03/2012 6:10 PM, Nils Loodin wrote: >> Resending this. Simple change, just need a reviewer from a JDK reviewer :) > > Looks good to me. > > David > - > >> Regards >> Nils Loodin >> >> On Mar 24, 2012, at 00:45 , Nils Loodin wrote: >> >>> Removed a folder in a jar-file and the classes into other folders, so some >>> of the lines in Release.gmk became unnecessary. >>> This should be cleaned up. >>> >>> Here's a very simple webrev: >>> http://cr.openjdk.java.net/~nloodin/7156000/webrev.00/ >>> >>> Regards >>> Nils Loodin >>
Re: Need JDK Reviewer for SIMPLE change! Free Karma!
On 27/03/2012 6:10 PM, Nils Loodin wrote: Resending this. Simple change, just need a reviewer from a JDK reviewer :) Looks good to me. David - Regards Nils Loodin On Mar 24, 2012, at 00:45 , Nils Loodin wrote: Removed a folder in a jar-file and the classes into other folders, so some of the lines in Release.gmk became unnecessary. This should be cleaned up. Here's a very simple webrev: http://cr.openjdk.java.net/~nloodin/7156000/webrev.00/ Regards Nils Loodin
Need JDK Reviewer for SIMPLE change! Free Karma!
Resending this. Simple change, just need a reviewer from a JDK reviewer :) Regards Nils Loodin On Mar 24, 2012, at 00:45 , Nils Loodin wrote: > Removed a folder in a jar-file and the classes into other folders, so some of > the lines in Release.gmk became unnecessary. > This should be cleaned up. > > Here's a very simple webrev: > http://cr.openjdk.java.net/~nloodin/7156000/webrev.00/ > > Regards > Nils Loodin
