Build problem (Windows, b24)

[Kelly O'Hair]

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
>  
>