How to check out the openjdk source code from the mercurial repositories

[Steve Poole]

On 11/03/11 17:06, Kelly O'Hair wrote:
>
> On Mar 11, 2011, at 2:04 AM, Steve Poole wrote:
>
>> On 11/03/11 01:14, David Holmes wrote:
>>> Dr Andrew John Hughes said the following on 03/11/11 10:57:
>>>> On 06:40 Fri 11 Mar     , David Holmes wrote:
>>>>> Stepping up a level, an initial download of openjdk need not involve
>>>>> using mercurial at all. You can simply download a stable snapshot 
>>>>> as a
>>>>> tar file; 
>>>>
>>>> This makes much more sense as a starting point for new users over 
>>>> having
>>>> to handle Mercurial and checkouts.  It works fine if you just want 
>>>> to _use_
>>>> the latest and greatest, not hack on it.
>>>
>>> Even if you want to hack you can still do your initial download this 
>>> way. The hg commands only come into play when you want to update 
>>> things later.
>>
>> That's the main point for me -  I want to get easy updates -  
>> checking out code from a repo is much nicer than having to download a 
>> tar and apply your changes.   Mercurials update and merge 
>> capabilities are great.
>>
>> BTW - its important that whatever process is documented is one that's 
>> used by developers.  So though it may be tempting to have complete 
>> snapshots of a build tree available -  unless someone actively proves 
>> they work, its best to have a singular process that *everyone* uses 
>> everyday.
>>
>
> A singular process that everyone uses?  Good Luck with that. I think 
> that is called "herding cats". :^)
> Sorry, I've been doing this too long, if there is a variation on doing 
> development and one person finds
> it productive for them, they will use it.
>
Sorry  - I was not being clear.    I meant that you must have one 
singular process that is the agreed "official" process.   If someone 
decides to do something different that's ok -  provided they understand 
that they have to take their lumps when and if they cause a break in the 
main build or cause testcases to fail.     The important point I was 
trying to make is that the process used by contributors must always 
work.  In my opinion the best way to achieve that is to ensure it's in 
use day by day.

> The complete OpenJDK source bundles are simply a forest with the .hg 
> directories removed, and they have
> only been provided for the community because they were asked for. They 
> are the same sources that are tagged
> as a promoted build, nothing special.
> I don't know any 'developers' that are using them, they use Mercurial/hg.
>
> Tools like Mercurial/Git allow for multiple clones and separate 
> development by different teams, so getting "updates" depends
> on where in the layers you want to get your "updates".
> The master forest from http://hg.openjdk.java.net/jdk7/jdk7 is updated 
> maybe twice a day, usually promoted
> and tagged once a week. Only the tagged 'promoted' sources that were 
> used to create our promoted jdk7 builds,
> can be guaranteed to be major disease (regression) free. See the 
> builds and integrations page at
> http://openjdk.java.net/projects/jdk7/builds/
>
> So the safest changes are probably available by doing a pull (or 
> fpull) with "--rev jdk7-bNNN", where NNN is
> currently 132 I think.
>
> Humm... maybe the RE team needs to create a jdk7-latest or jdk7-ea tag 
> at each promotion?
>
> -kto
>
>> Checking out using hg is simple - the only wart is the forest 
>> extension and that's only because its unclear what the community view 
>> is on using it.
>>>
>>>>> or download an install script that will do whatever is
>>>>> necessary behind the scenes to get a complete openjdk.
>>>>
>>>> I don't know how that would work.  I guess IcedTea comes close to 
>>>> this idea
>>>> in that it detects the needed settings for the build, rather than 
>>>> them all
>>>> having to be passed as make variables.
>>>
>>> I was thinking of a simple installer as used by various bits of 
>>> software. For example for Linux you might download a script that 
>>> simply contains the initial set of hg commands needed to get the 
>>> forest. On windows it might automate downloading a tarball and 
>>> extracting it.
>>>
>>>>> Personally I'd
>>>>> like to see that include the basic build tools as well - in which 
>>>>> case I
>>>>> don't care about "special extensions" as I just get a working 
>>>>> toolkit. 
>>>>
>>>> What do you mean by this?  Can you give an example?
>>>
>>> I know this is not what most people want and not how most OS handle 
>>> software packaging these days, but I think it would be useful to be 
>>> able to grab a tools bundles for a given OS that includes the 
>>> various tools and extras you need eg mercurial, ant, gcc, freetype - 
>>> all the things the build docs tell you that you have to go and get 
>>> to build openjdk. Just yesterday I had to go and grab freetype and 
>>> get it installed on a machine; today I've had to install gawk and 
>>> libasound2-dev. I find this a PITA.
>>>
>>> I don't expect to see this happen, my point was that if you did have 
>>> easy access to pre-packaged tools, then it wouldn't matter if 
>>> openjdk required customized variants of those tools.
>>>
>>> David
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20110315/ccd9991e/attachment.htm>