Building OpenJDK 7 on Windows XP

Jonathan Gibbons Jonathan.Gibbons at Sun.COM
Tue May 20 02:55:28 UTC 2008


True, and to be fair, the BUILD readme is quite good.  Perhaps I'd be 
happy with a simple
short table in the developers guide that at least gives me one place to 
go to find a list of
everything I need, with (references to) info on where to get and how to 
"use" those tools.
 (ie what env variables to set.)

-- Jon


Kelly O'Hair wrote:
> It is a "BUILD" readme. The development requirements are a separate
> thing, perhaps that should be documented in the development guide?
>
> Yes, we should add "ant" as a build requirement, I'll fix that.
>
> ---
>
> Trying to satisfy everyone with the build configurations is frustrating
> to say the least.
> If you drew a venn diagram of what everybody wants in the build system,
> I'm not sure the overlapping parts are all that large. :^(
>
> -kto
>
> Jonathan Gibbons wrote:
>> Kelly, Max,
>>
>> That list mostly covers what you need for a build (Ant does not seem 
>> to be present, required
>> by langtools), but it bdoesn't cover everything you may need to work 
>> on OpenJDK, and it
>> doesn't particularly encourage a single shared tree.
>>
>> As Max points out, you can get by with a single setting, but the 
>> hierarchy is somewhat
>> weird and betrays more than a little bit of its Sun history :-)  And, 
>> as more tools get involved,
>> the current system of lots of separate env variables might not scale 
>> well.
>>
>> Although not required for the build, the page does not list 
>> additional tools that may be required
>> for working on OpenJDK -- Mercurial, official Mercurial extensions 
>> (forest), OpenJDK Mercurial
>> extensions (jcheck), other tools (FindBugs, etc)
>>
>> -- Jon
>>
>>
>> Max (Weijun) Wang wrote:
>>> One setting is enough, if the directory structure is right:
>>>
>>> $ALT_SLASH_JAVA
>>>    devtools
>>>       share
>>>          ant...
>>>          findbugs...
>>>          plugin
>>>             mozilla_headers_18.win32...
>>>       Windows
>>>          DXSDK...
>>>    re
>>>       jdk
>>>          1.6.0/archive/fcs/binaries/windows-i586...
>>>          1.7.0/promoted/latest/binaries/windows-i586...
>>>          (I hope the last 2 are correct)
>>>
>>> and, a very clean instruction:
>>>
>>> 1. Open the VC++.2003 Command prompt
>>> 2. call c:\cygwin\cygwin.bat
>>> 3. cd myjdk
>>> 4. /cygdrive/c/precious/make380.exe
>>>
>>> Max
>>>
>>> On May 20, 2008, at 2:31 AM, Kelly O'Hair wrote:
>>>>
>>>> I tried to provide that list at:
>>>>
>>>>    
>>>> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#windows 
>>>>
>>>>
>>>> Did I miss the target somehow?
>>>>
>>>> -kto
>>>>
>>>>
>>>> Jonathan Gibbons wrote:
>>>>> Martin,
>>>>> I'd settle for just a *list* of all the tools you need, and have 
>>>>> the JDK
>>>>> build able to find all the tools given a minimum of ALT variable 
>>>>> settings.
>>>>> For licensing reasons, I suspect Sun cannot redistribute many of 
>>>>> the tools,
>>>>> but if the user could populate such a tree, then any version of 
>>>>> OpenJDK
>>>>> should be able to build with it, with perhaps just one ALT_TOOLS 
>>>>> setting.
>>>>> -- Jon
>>>>> On May 19, 2008, at 9:02 AM, Martin Buchholz wrote:
>>>>>> I propose that Sun create an externally-visible tree of binaries
>>>>>> in the form that the JDK makefiles expect for ALT_SLASH_JAVA.
>>>>>> Then OpenJDK developers could copy this tree to their development
>>>>>> machine, set ALT_SLASH_JAVA to this directory, and most of
>>>>>> the sanity warnings would evaporate.
>>>>>>
>>>>>> Of course, this may not be possible for everything that is
>>>>>> expected to be found in ALT_SLASH_JAVA.  E.g. Sun compilers
>>>>>> probably cannot be provided this way, because of the usual
>>>>>> requirement to have click-through licenses?!
>>>>>> Perhaps Sun could aggregate a complete JDK development
>>>>>> environment in one mega-tarball, protected by just one
>>>>>> click-through license?
>>>>>>
>>>>>> Perhaps Sun could provide a known-to-work copy of Cygwin
>>>>>> for JDK development.  The Cygwin project itself doesn't provide
>>>>>> historic binaries, but if you install Cygwin by first downloading
>>>>>> everything to disk, and then installing from there, you'll have
>>>>>> a frozen-in-time set of Cygwin binaries that you can probably
>>>>>> legally redistribute later when they've gotten the thumbs-up
>>>>>> from Sun JDK development engineers.
>>>>>>
>>>>>> Martin
>>>
>>




More information about the build-dev mailing list