harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [build] managing external dependencies
Date Mon, 21 Jan 2008 12:58:10 GMT

On 21 January 2008 at 12:20, Tim Ellison <t.p.ellison@gmail.com> 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 <mark.hindess@googlemail.com> 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"
> >> <alexey.a.petrenko@gmail.com> wrote:
> >>> Thanks, Mark!
> >>>
> >>> SY, Alexey
> >>>
> >>> 2008/1/16, Mark Hindess <mark.hindess@googlemail.com>:
> >>>> On 16 January 2008 at 15:53, "Alexey Petrenko" <alexey.a.petrenko@gmail.
> c
> >> om
> >>>> wrote:
> >>>>> 2008/1/16, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
> >>>>>> 2008/1/9, Mark Hindess <mark.hindess@googlemail.com>:
> >>>>>>> On 9 January 2008 at 19:07, "Alexey Varlamov" <alexey.v.varlamov@gm
> >> 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.
> >>>>
> >>>>
> >>>>
> > 
> > 
> > 
> 



Mime
View raw message