Build problem (Windows, b24)

[Ted Neward]

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