BTW, when I set ALT_OUTPUTDIR to C:/Prg/OpenJDK/output/jdk7 (in other words, use the DOS-forward-slash paths), the top-level make seems to honor it, but just one or two levels down (make[2], I think) it's clearly been reset to "ALT_OUTPUTDIR=./build/windows-...", which is obviously not correct.
Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:build-dev- > [EMAIL PROTECTED] On Behalf Of Ted Neward > Sent: Sunday, December 30, 2007 8:28 PM > To: [EMAIL PROTECTED] > Cc: 'build-dev'; [EMAIL PROTECTED] > Subject: RE: Build problem (Windows, b24) > > I dunno if I changed it since the blog post (I'll have to update it > once I > get this all working again), but right now it reads: > > export ALT_JDK_IMPORT_PATH=C:/Prg/jdk1.6.0 > > In other words, exactly what you say it should read, minus the quotes. > Are > the quotes necessary? I've not used them before, up 'til now. > > env|grep ALT_ shows everything having C:/ style paths in it. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Sunday, December 30, 2007 4:06 PM > > To: Ted Neward > > Cc: 'build-dev'; [EMAIL PROTECTED] > > Subject: Re: Build problem (Windows, b24) > > > > > > This could be a problem: > > > > export ALT_JDK_IMPORT_PATH=$(cygpath --unix C:/Prg/jdk1.6.0) > > > > Should just be: > > > > export ALT_JDK_IMPORT_PATH="C:/Prg/jdk1.6.0" > > > > None of the ALT variables should use the cygwin/unix style paths. > > > > Can you send what 'env|grep ALT_' says? > > > > -kto > > > > Ted Neward wrote: > > > Make is 3.80; it's the one I pulled down from other email threads > > here. That > > > shouldn't be an issue; that said, I'll double-check. > > > > > > I think the sanity messages are printing out the "8.3" versions of > > directory > > > names, though. That's not good, I take it? > > > > > > OUTPUTDIR is definitely a read/write directory, so that shouldn't > be > > the > > > case. > > > > > > What *should* my env vars look like? Currently they look like the > > blog post > > > I put up a few days ago--is that correct? I thought I remember you > > saying > > > they should all look like the form "C:/Prg/OpenJDK/..." (forward > > slashed > > > DOS-like paths). Yes? > > > > > > Ted Neward > > > Java, .NET, XML Services > > > Consulting, Teaching, Speaking, Writing > > > http://www.tedneward.com > > > > > >> -----Original Message----- > > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > >> Sent: Saturday, December 29, 2007 10:35 AM > > >> To: Ted Neward > > >> Cc: 'build-dev'; [EMAIL PROTECTED] > > >> Subject: Re: Build problem (Windows, b24) > > >> > > >> Is it possible that the sanity messages are printing out the > 'short > > >> path' > > >> version of your output directory? e.g. cygpath -m -s > > >> "C:/Prg/OpenJDK/build" > > >> > > >> Assuming you are using the cygwin 'make' do you know what version > it > > >> is? > > >> Is it 3.81? > > >> > > >> I do recall some logic in the Makefiles that trys to deal with the > > >> situation > > >> where the OUTPUTDIR is not a read-write directory, and ignored it, > > >> using > > >> a different default that was read-write. > > >> > > >> -kto > > >> > > >> Ted Neward wrote: > > >>> Maybe I'm not getting it, but "make > > >> ALT_OUTPUTDIR=C:/Prg/OpenJDK/build ..." > > >>> doesn't seem to take. When I do the build, the sanity portion of > > the > > >> build > > >>> reports ALT_OUTPUTDIR being set to something other than what I > > >> specify on > > >>> the build command-line. What am I not getting? > > >>> > > >>> Along those same lines, how can I see the recursive make calls > more > > >>> explicitly? > > >>> > > >>> Ted Neward > > >>> Java, .NET, XML Services > > >>> Consulting, Teaching, Speaking, Writing > > >>> http://www.tedneward.com > > >>> > > >>>> -----Original Message----- > > >>>> From: Ted Neward [mailto:[EMAIL PROTECTED] > > >>>> Sent: Wednesday, December 26, 2007 3:56 PM > > >>>> To: 'Ted Neward'; [EMAIL PROTECTED] > > >>>> Cc: 'build-dev'; [EMAIL PROTECTED] > > >>>> Subject: RE: Build problem (Windows, b24) > > >>>> > > >>>> Something strange is going on. When I build from the top-level > > >>>> directory, it > > >>>> fails to build java/hpi. When I build just one level down, using > > >>>> Kelly's > > >>>> "make all ..." syntax below, it builds fine. Hate to say it, but > I > > >>>> think > > >>>> this may be a bug in the Makefiles, though I'm not sure where or > > >>>> why...? > > >>>> > > >>>> Ted Neward > > >>>> Java, .NET, XML Services > > >>>> Consulting, Teaching, Speaking, Writing > > >>>> http://www.tedneward.com > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: [EMAIL PROTECTED] [mailto:build-dev- > > >>>>> [EMAIL PROTECTED] On Behalf Of Ted Neward > > >>>>> Sent: Wednesday, December 26, 2007 1:03 PM > > >>>>> To: [EMAIL PROTECTED] > > >>>>> Cc: 'build-dev'; [EMAIL PROTECTED] > > >>>>> Subject: RE: Build problem (Windows, b24) > > >>>>> > > >>>>> OK, trying to get back into this. > > >>>>> > > >>>>> (*) FWICT, ALT_OUTPUTDIR doesn't seem to "take" when set from > the > > >>>>> command > > >>>>> shell as an environment variable. Is this supposed to work? > > >>>>> (*) When I do cd jdk/make/java/hpi && make VARIANT=DBG > > >>>> FASTDEBUG=true, > > >>>>> I get > > >>>>> nothing. No build, no error, just... enters windows, leaves > > >> windows, > > >>>>> done. > > >>>>> > > >>>>> I'm doing a full build (from the top) into a log file for > > >> attachment > > >>>> to > > >>>>> this > > >>>>> thread now, will email it when it's done. Problem is, I can't > > tell > > >> if > > >>>>> it's > > >>>>> an environment issue, or a genuine bug in the makefiles, or a > > >> PEBKAC > > >>>>> problem. Suggestions welcome.... > > >>>>> > > >>>>> Ted Neward > > >>>>> Java, .NET, XML Services > > >>>>> Consulting, Teaching, Speaking, Writing > > >>>>> http://www.tedneward.com > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > >>>>>> Sent: Tuesday, December 18, 2007 11:58 AM > > >>>>>> To: Ted Neward > > >>>>>> Cc: [EMAIL PROTECTED]; 'build-dev' > > >>>>>> Subject: Re: Build problem (Windows, b24) > > >>>>>> > > >>>>>> > > >>>>>> Do to history, a build directly from the jdk/make directories > > uses > > >>>> a > > >>>>>> default > > >>>>>> OUTPUTDIR of jdk/build/* but if FASTDEBUG=true, it's > > jdk/build/*- > > >>>>>> fastdebug, > > >>>>>> or if a plain debug build with just VARIANT=DBG it would be > > >>>>>> jdk/build/*-debug > > >>>>>> The variant builds leave results in a completely separate > > >>>> outputdir. > > >>>>>> If you used the very top level makefile (which came from the > now > > >>>>>> defunct control/make area) > > >>>>>> the default OUTPUTDIR is ./build/* (at the very top of the > > >>>>>> repositories). > > >>>>>> When this top level Makefile runs the jdk/make Makefiles, it > > >> passes > > >>>>> in > > >>>>>> a ALT_OUTPUTDIR > > >>>>>> to refer to this top level build result area because it's > > default > > >>>>>> outputdir > > >>>>>> is not the same place. > > >>>>>> > > >>>>>> I don't know the complete history as to why this was done this > > >> way, > > >>>>> but > > >>>>>> my > > >>>>>> tendency is to try and get us back to a single default > OUTPUTDIR > > >>>> for > > >>>>>> all the > > >>>>>> repositories. Someday... > > >>>>>> > > >>>>>> This is what I do when I work on just the jdk repository: > > >>>>>> cd jdk/make && gnumake > > >>>>>> That primes the outputdir area, then I can drop down in: > > >>>>>> cd jdk/make/java && gnumake > > >>>>>> Or even drop in and clean an area and re-build it: > > >>>>>> cd jdk/make/jpda && gnumake clean && gnumake > > >>>>>> Or just repeat the entire build (incremental build) > > >>>>>> cd jdk/make && gnumake > > >>>>>> If I wanted the jdk image (j2sdk-image), I would need to: > > >>>>>> cd jdk/make && gnumake image > > >>>>>> > > >>>>>> But the output by default will go to jdk/build/* > > >>>>>> and a different directory if VARIANT=DBG or FASTDEBUG=true. > > >>>>>> > > >>>>>> I think you need to: > > >>>>>> cd jdk/make && gnumake VARIANT=DBG FASTDEBUG=true > > >>>>>> Then see if you can: > > >>>>>> cd jdk/make/java/hpi && gnumake VARIANT=DBG FASTDEBUG=true > > >>>>>> > > >>>>>> -kto > > >>>>>> > > >>>>>> Ted Neward wrote: > > >>>>>>> Tim-- > > >>>>>>> > > >>>>>>>> Maybe you came in too low and clipped the treetops. > > >>>>>>>> > > >>>>>>> I thought part of the idea would be that if I've just made a > > >>>> change > > >>>>>> to one > > >>>>>>> part of the tree, I don't have to rebuild the whole tree, so > I > > >>>>> would > > >>>>>> think > > >>>>>>> coming in lower to the ground would be supported...? > > >>>>>>> > > >>>>>>> Let's turn it around this way: what is Sun doing among the > > >>>> various > > >>>>>> teams? If > > >>>>>>> a developer makes a change, say, to the java.lang.instrument > > >>>>> package, > > >>>>>> what's > > >>>>>>> the quickest way to get his build, presuming that he hasn't > > >>>> changed > > >>>>>> anything > > >>>>>>> outside of that directory? I don't want to be swimming > > upstream, > > >>>>> but > > >>>>>> in this > > >>>>>>> case, I really don't know which way the water flows. :-) > > >>>>>>> > > >>>>>>>> Try your 'make all' from > > >>>>> [...]/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make > > >>>>>>> Will do; by the way, what targets are supported in these > lower- > > >>>>> level > > >>>>>> makes? > > >>>>>>> "fastdebug" and "fastdebug_build" didn't take, AFAICT (no > > >>>> target). > > >>>>>>>> The first thing the jdk7/jdk build does (after the sanity > > check) > > >>>>> is > > >>>>>>>> create a number of tools > > >>>>>>>> that will be used later. If you start building lower down > in > > >>>>>>>> jdk/make/java there may be an > > >>>>>>>> assumption about work that has already been done. > > >>>>>>>> > > >>>>>>> I can see that, and they are there--they built successfully. > > What > > >>>> I > > >>>>>> don't > > >>>>>>> understand is why the "treetop build" I tried was looking for > > >>>> them > > >>>>> in > > >>>>>>> windows-i586 and not windows-i586-fastdebug. > > >>>>>>> > > >>>>>>>> This is not automatic because we don't want to fill up > > someone's > > >>>>>> disk > > >>>>>>>> space with log files. > > >>>>>>>> Not so much of a problem these days, but back in the early > > days > > >>>> it > > >>>>>> was. > > >>>>>>> Maybe an option flag/env var in the make set, a la > > >>>>> ALT_LOGFILES=false > > >>>>>> to > > >>>>>>> turn them off or something? It's just a common thing to have > > the > > >>>>>> build tool > > >>>>>>> logging this stuff these days, it seems. > > >>>>>>> > > >>>>>>> Ted Neward > > >>>>>>> Java, .NET, XML Services > > >>>>>>> Consulting, Teaching, Speaking, Writing > > >>>>>>> http://www.tedneward.com > > >>>>>>> > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > >>>>>>>> Sent: Tuesday, December 18, 2007 12:12 AM > > >>>>>>>> To: Ted Neward > > >>>>>>>> Cc: 'build-dev' > > >>>>>>>> Subject: Re: Build problem (Windows, b24) > > >>>>>>>> > > >>>>>>>> Hi - > > >>>>>>>> > > >>>>>>>>> > OpenJDK:[EMAIL PROTECTED]:/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make/java > > >>>>>>>>> $ make all > > >>>>>>>> Maybe you came in too low and clipped the treetops. > > >>>>>>>> > > >>>>>>>> Try your 'make all' from > > >>>>> [...]/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make > > >>>>>>>> The first thing the jdk7/jdk build does (after the sanity > > check) > > >>>>> is > > >>>>>>>> create a number of tools > > >>>>>>>> that will be used later. If you start building lower down > in > > >>>>>>>> jdk/make/java there may be an > > >>>>>>>> assumption about work that has already been done. > > >>>>>>>> > > >>>>>>>> So try it again from > > [...]/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make > > >>>>>>>> > > >>>>>>>> BTW - I always save the build log, as Kelly wrote: > > >>>>>>>> > > >>>>>>>>> make |& tee build.log or make >& build.log > > >>>>>>>> This is not automatic because we don't want to fill up > > someone's > > >>>>>> disk > > >>>>>>>> space with log files. > > >>>>>>>> Not so much of a problem these days, but back in the early > > days > > >>>> it > > >>>>>> was. > > >>>>>>>> HTH - Tim > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> Begin Processing SUBDIRS: hpi version jvm redist verify > > fdlibm > > >>>>> java > > >>>>>>>> sun_nio > > >>>>>>>>> jli > > >>>>>>>>> main zip security npt java_crw_demo java_hprof_demo math > awt > > >>>> util > > >>>>>>>> text > > >>>>>>>>> applet ne > > >>>>>>>>> t nio sql rmi jar beans logging management instrument > > >>>>>>>>>>>> Recursively making hpi all @ Mon Dec 17 23:40:21 PST > 2007 > > >>>> ... > > >>>>>>>>> make[1]: Entering directory > > >>>>>>>> `/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make/java/hpi' > > >>>>>>>>> Begin Processing SUBDIRS: windows > > >>>>>>>>>>>> Recursively making windows all @ Mon Dec 17 23:40:25 PST > > >>>> 2007 > > >>>>>> ... > > >>>>>>>>> make[2]: Entering directory > > >>>>>>>>> `/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make/java/hpi/wind > > >>>>>>>>> ows' > > >>>>>>>>> make[2]: *** No rule to make target > > >>>>>>>>> `../../../../build/windows-i586/btjars/strip > > >>>>>>>>> properties.jar', needed by `strip_all_props'. Stop. > > >>>>>>>>> make[2]: Leaving directory > > >>>>>>>>> `/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make/java/hpi/windo > > >>>>>>>>> ws' > > >>>>>>>>> make[1]: *** [all] Error 1 > > >>>>>>>>> make[1]: Leaving directory > > >>>>>>>> `/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make/java/hpi' > > >>>>>>>>> make: *** [all] Error 1 > > >>>>>>>>> > OpenJDK:[EMAIL PROTECTED]:/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make/java > > >>>>>>>>> $ > > >>>>>>>> No virus found in this incoming message. > > >>>>>>>> Checked by AVG Free Edition. > > >>>>>>>> Version: 7.5.503 / Virus Database: 269.17.2/1185 - Release > > Date: > > >>>>>>>> 12/15/2007 12:00 PM > > >>>>>>>> > > >>>>>>> No virus found in this outgoing message. > > >>>>>>> Checked by AVG Free Edition. > > >>>>>>> Version: 7.5.503 / Virus Database: 269.17.2/1185 - Release > > Date: > > >>>>>> 12/15/2007 > > >>>>>>> 12:00 PM > > >>>>>>> > > >>>>>>> > > >>>>>> No virus found in this incoming message. > > >>>>>> Checked by AVG Free Edition. > > >>>>>> Version: 7.5.503 / Virus Database: 269.17.2/1185 - Release > Date: > > >>>>>> 12/15/2007 12:00 PM > > >>>>>> > > >>>>> No virus found in this outgoing message. > > >>>>> Checked by AVG Free Edition. > > >>>>> Version: 7.5.516 / Virus Database: 269.17.9/1197 - Release > Date: > > >>>>> 12/25/2007 > > >>>>> 8:04 PM > > >>>>> > > >>>>> > > >>>>> No virus found in this incoming message. > > >>>>> Checked by AVG Free Edition. > > >>>>> Version: 7.5.516 / Virus Database: 269.17.9/1197 - Release > Date: > > >>>>> 12/25/2007 8:04 PM > > >>>>> > > >>>> No virus found in this outgoing message. > > >>>> Checked by AVG Free Edition. > > >>>> Version: 7.5.516 / Virus Database: 269.17.9/1197 - Release Date: > > >>>> 12/25/2007 > > >>>> 8:04 PM > > >>>> > > >>>> > > >>>> No virus found in this incoming message. > > >>>> Checked by AVG Free Edition. > > >>>> Version: 7.5.516 / Virus Database: 269.17.9/1197 - Release Date: > > >>>> 12/25/2007 8:04 PM > > >>>> > > >>> No virus found in this outgoing message. > > >>> Checked by AVG Free Edition. > > >>> Version: 7.5.516 / Virus Database: 269.17.9/1197 - Release Date: > > >> 12/25/2007 > > >>> 8:04 PM > > >>> > > >>> > > >> No virus found in this incoming message. > > >> Checked by AVG Free Edition. > > >> Version: 7.5.516 / Virus Database: 269.17.12/1202 - Release Date: > > >> 12/29/2007 1:27 PM > > >> > > > > > > No virus found in this outgoing message. > > > Checked by AVG Free Edition. > > > Version: 7.5.516 / Virus Database: 269.17.12/1202 - Release Date: > > 12/29/2007 > > > 1:27 PM > > > > > > > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.17.12/1203 - Release Date: > > 12/30/2007 11:27 AM > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.17.12/1203 - Release Date: > 12/30/2007 > 11:27 AM > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.17.12/1203 - Release Date: > 12/30/2007 11:27 AM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.12/1203 - Release Date: 12/30/2007 11:27 AM
