Build problem (Windows, b24)

Kelly O'Hair Kelly.Ohair at Sun.COM
Mon Dec 31 00:05:35 UTC 2007 

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

More information about the build-dev mailing list