Build problem (Windows, b24)

[Ted Neward]

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: build-dev-bounces at openjdk.java.net [mailto:build-dev-
> bounces at openjdk.java.net] On Behalf Of Ted Neward
> Sent: Sunday, December 30, 2007 8:28 PM
> To: Kelly.Ohair at Sun.COM
> Cc: 'build-dev'; Tim.Bell at Sun.COM
> 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: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM]
> > Sent: Sunday, December 30, 2007 4:06 PM
> > To: Ted Neward
> > Cc: 'build-dev'; Tim.Bell at Sun.COM
> > 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: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM]
> > >> Sent: Saturday, December 29, 2007 10:35 AM
> > >> To: Ted Neward
> > >> Cc: 'build-dev'; Tim.Bell at Sun.COM
> > >> 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:ted at tedneward.com]
> > >>>> Sent: Wednesday, December 26, 2007 3:56 PM
> > >>>> To: 'Ted Neward'; Kelly.Ohair at Sun.COM
> > >>>> Cc: 'build-dev'; Tim.Bell at Sun.COM
> > >>>> 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: build-dev-bounces at openjdk.java.net [mailto:build-dev-
> > >>>>> bounces at openjdk.java.net] On Behalf Of Ted Neward
> > >>>>> Sent: Wednesday, December 26, 2007 1:03 PM
> > >>>>> To: Kelly.Ohair at Sun.COM
> > >>>>> Cc: 'build-dev'; Tim.Bell at Sun.COM
> > >>>>> 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: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM]
> > >>>>>> Sent: Tuesday, December 18, 2007 11:58 AM
> > >>>>>> To: Ted Neward
> > >>>>>> Cc: Tim.Bell at Sun.COM; '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: Tim.Bell at Sun.COM [mailto:Tim.Bell at Sun.COM]
> > >>>>>>>> Sent: Tuesday, December 18, 2007 12:12 AM
> > >>>>>>>> To: Ted Neward
> > >>>>>>>> Cc: 'build-dev'
> > >>>>>>>> Subject: Re: Build problem (Windows, b24)
> > >>>>>>>>
> > >>>>>>>> Hi -
> > >>>>>>>>
> > >>>>>>>>>
> OpenJDK:Ted at XPJAVA:/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:Ted at XPJAVA:/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