harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sian January" <sianjanu...@googlemail.com>
Subject Re: [build] managing external dependencies
Date Mon, 21 Jan 2008 09:20:11 GMT
Hi Mark,

I've just tried your patch on Windows and it works as you described.

Regards,

Sian


On 18/01/2008, Mark Hindess <mark.hindess@googlemail.com> 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>
> 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.
> > > >
> > > >
> > > >
> > >
> >
>
>
>


-- 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message