Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (athena.apache.org: 212.159.14.134 is neither permitted
 nor denied by domain of mark.hindess@googlemail.com)
In-reply-to: <20080117194502.604CE4DA0AD@nike.apache.org> 
References: <f944d83d0801090507m7b9f08bcg1a53d8250d6e6825@mail.gmail.com>
 <200801091540.m09FeSUE032259@d06av01.portsmouth.uk.ibm.com>
 <f944d83d0801160407v63094884vf5ebe453c4af88d4@mail.gmail.com>
 <c3755b3a0801160453u39032e42l6140665ba4f24fad@mail.gmail.com>
 <200801161529.m0GFTcev006953@d12av02.megacenter.de.ibm.com>
 <c3755b3a0801170031l294102e1m611623d9ba594892@mail.gmail.com>
 <20080117194502.604CE4DA0AD@nike.apache.org>
Comments: In-reply-to Mark Hindess <mark.hindess@googlemail.com>
   message dated "Thu, 17 Jan 2008 19:44:05 +0000."
From: Mark Hindess <mark.hindess@googlemail.com>
To: dev@harmony.apache.org
Subject: Re: [build] managing external dependencies 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 Jan 2008 22:25:42 +0000
Message-Id: <20080118222628.56DFC724954@athena.apache.org>


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> wrote:
> 
> 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.
> > >
> > >
> > >
> > 
>