Build problem (Windows, b24)

[Kelly O'Hair]

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