Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 86330 invoked from network); 21 Jan 2008 12:58:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 Jan 2008 12:58:49 -0000 Received: (qmail 52597 invoked by uid 500); 21 Jan 2008 12:58:37 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 52574 invoked by uid 500); 21 Jan 2008 12:58:37 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 52565 invoked by uid 99); 21 Jan 2008 12:58:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Jan 2008 04:58:36 -0800 X-ASF-Spam-Status: No, hits=-2.8 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 195.212.29.141 is neither permitted nor denied by domain of mark.hindess@googlemail.com) Received: from [195.212.29.141] (HELO mtagate8.uk.ibm.com) (195.212.29.141) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Jan 2008 12:58:22 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate8.uk.ibm.com (8.13.8/8.13.8) with ESMTP id m0LCwENW109052 for ; Mon, 21 Jan 2008 12:58:14 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m0LCwEeI4902928 for ; Mon, 21 Jan 2008 12:58:14 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m0LCwAhW028555 for ; Mon, 21 Jan 2008 12:58:10 GMT Received: from anaheim.local (anaheim.hursley.ibm.com [9.20.183.13]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m0LCwAZm028546 for ; Mon, 21 Jan 2008 12:58:10 GMT Message-Id: <200801211258.m0LCwAZm028546@d06av02.portsmouth.uk.ibm.com> X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-9) with nmh-1.2 In-reply-to: <47948E04.9060903@gmail.com> References: <200801091540.m09FeSUE032259@d06av01.portsmouth.uk.ibm.com> <200801161529.m0GFTcev006953@d12av02.megacenter.de.ibm.com> <20080117194502.604CE4DA0AD@nike.apache.org> <20080118222628.56DFC724954@athena.apache.org> <47948E04.9060903@gmail.com> Comments: In-reply-to Tim Ellison message dated "Mon, 21 Jan 2008 12:20:20 +0000." From: Mark Hindess To: dev@harmony.apache.org Subject: Re: [build] managing external dependencies Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jan 2008 12:58:10 +0000 X-Virus-Checked: Checked by ClamAV on apache.org On 21 January 2008 at 12:20, Tim Ellison wrote: > I just updated to r613866 (from being a bit behind doing the merge work) > and when I ran fetch-depends it failed in the way Stepan described: > > File depends/libs/windows.x86/icu-3.4/icu-3.4.zip has incorrect md5 > checksum. > Expected: 4ab256e309d1ceb9779b10cf32c79dab (or ) > Found: f8b46d05e08ca98e42738f159ae1dd40 > > So I deleted the depends/libs/windows.x86/icu-3.4 directory and fetched > the dependencies again (and it worked). > > Regards, > Tim Damn. I think you only get the warning that tells you what to do if you run "check-depends". The bad news is I need to break it again ... this time for bcprov in order to move the download to a non-bouncycastle.org server as they requested last year. A similar fix will apply; removing the depends/jars/bcprov-jdk15-138 directory. Regards, Mark. > Mark Hindess wrote: > > Could someone with windows who has run a build since r612947 but before > > r613291 please test the patch attached to: > > > > https://issues.apache.org/jira/browse/HARMONY-5405 > > > > I'd like to check that it correctly forces people to get the updated > > zip file (containing a .lib file) and that the rest of the cleanup > > in the patch[0] doesn't break the build. > > > > Thanks, > > Mark. > > > > [0] There were two separate sections in the build-native.xml copying > > the icu link-against libraries - one for z/os .x files and one for > > windows .lib files. The .lib file was also copied in to the hdk on > > linux which was a little bit pointless. > > > > On 17 January 2008 at 19:44, Mark Hindess wro > te: > >> I've committed r612947 with the trickiest part of the icu dll > >> restructuring now. Hopefully I've not broken too much. > >> > >> A clean (pre-fetch-depends) classlib svn tree shrinks from 542M to just > >> 265M. Of course, some of it will be added back by fetch-depends but > >> even so that is a massive improvement. > >> > >> Thanks to Tim for prompting me to do this - though typically it turned > >> out to be a can of worms[0]. > >> > >> Regards, > >> Mark. > >> > >> [0] http://www.answers.com/topic/can-of-worms > >> > >> On 17 January 2008 at 11:31, "Alexey Petrenko" > >> wrote: > >>> Thanks, Mark! > >>> > >>> SY, Alexey > >>> > >>> 2008/1/16, Mark Hindess : > >>>> On 16 January 2008 at 15:53, "Alexey Petrenko" c > >> om > >>>> wrote: > >>>>> 2008/1/16, Alexey Varlamov : > >>>>>> 2008/1/9, Mark Hindess : > >>>>>>> On 9 January 2008 at 19:07, "Alexey Varlamov" >> ai > >>> l.co > >>>>> m> wrote: > >>>>>>>> Folks, > >>>>>>>> > >>>>>>>> We did a few iterations refactoring the subject - let's have one > >> mo > >>> re a > >>>>> ccess > >>>>>>>> ;). > >>>>>>>> Why? There was a desire to have the following: > >>>>>>>> 1) More fine-grained control over dependencies to empower modular > >> it > >>> y; > >>>>>>>> 2) Unified approach and shared scripts across Harmony modules - V > >> Ms > >>> , > >>>>>>>> classlib, jdktools; > >>>>>>>> 3) Reduce duplication of resources (traffic, space, etc) between > >>>>>>>> modules within the same workspace; > >>>>>>>> I'd also add 4) If possible, reuse resources in different workspa > >> ce > >>> s. > >>>>>>>> This would be quite handy for committing purposes and for > >>>>>>>> multi-platform development. > >>>>>>> I like all of the above but would add Tim's suggestion from a few w > >> ee > >>> ks > >>>>>>> back which I think was something like: > >>>>>>> > >>>>>>> 5) Move binary dependencies - like all the icu libs - from the enha > >> nc > >>> ed > >>>>>>> to the standard tree in svn and download them via http as we do oth > >> er > >>>>>>> dependencies during the fetch-depends stage. > >>>>>> +1. Checking out tens of megabytes of unrelated binaries is really an > >> no > >>> ying > >>>>> ! > >>>>> +1 > >>>> I started looking at fixing this earlier today ... making steady > >>>> progress but I've just got a new laptop so I am a little distracted now. > >>>> > >>>> -Mark. > >>>> > >>>> > >>>> > > > > > > >