Build problem (Windows, b24)

[Ted Neward]

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