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 Tue, 22 Jan 2008 20:11:40 GMT

On 22 January 2008 at 22:32, "Alexey Petrenko" <alexey.a.petrenko@gmail.com> 
wrote:
> I got the following error on federated build which looks as a result
> of this change:

Can you explain why you think that this is the result of my recent changes?

Nothing I did creates the file (actually a symlink I imagine) that the
error message claims exists.  The only thing I can find that creates it
is the line in the vmcore.xml build file.

To be honest, this has puzzled me for a while and needs fixing for
several reasons:

1) I added a delete to try to make sure the target of the symlink
   was missing (I did this at least a week ago not as part of the
   recent changes.)

2) the symlink task has overwrite="yes" which I'd imagine would
   force the overwriting of the existing symlink but then it seems
   to be executing "ln -s" rather than "ln -sf" as one might expect.

3) drlvm build shouldn't really be modifying classlib files like
   this anyway - and if it does it should really remove anything
   created as part of the drlvm clean target.

4) Despite my attempts to patch over this problem (see 1) I still
   get problems with packaging for debian because of this error.

I haven't bothered to look at it further because I was hoping these
files would be moved to common_resources (since they aren't needed
by classlib any more only by drlvm) and that the problem would
be removed in the process.

I was making this batch of icu dependency improvements because I think
it should make it easier to move them to common_resources and
because it brings an immediate benefit in terms of checkout size/time.

Regards,
-Mark

> === cut ===
>      [exec] -init-unix:
>      [exec]   [symlink] ln -s
> /localdisk/aapetren/harmony/working_classlib/depends/libs/linux.x86/icu-3.4/l
> ibicuuc.so.34
> /localdisk/aapetren/harmony/working_classlib/depends/libs/linux.x86/icu-3.4/l
> ibicuuc.so
>      [exec]   [symlink] /bin/ln: creating symbolic link
> `/localdisk/aapetren/harmony/working_classlib/depends/libs/linux.x86/icu-3.4/
> libicuuc.so':
> File exists
> 
>      [exec] BUILD FAILED
>      [exec] /localdisk/aapetren/harmony/working_vm/build/make/build.xml:600:
> The following error occurred while executing this line:
>      [exec] /localdisk/aapetren/harmony/working_vm/build/make/build.xml:607:
> The following error occurred while executing this line:
>      [exec] /localdisk/aapetren/harmony/working_vm/build/make/build_component
> .xml:74:
> The following error occurred while executing this line:
>      [exec] /localdisk/aapetren/harmony/working_vm/build/lnx_ia32_gcc_release
> /semis/build/init_vm.vmcore.xml:23:
> ln failed with return code 1
> 
>      [exec] Total time: 2 minutes 36 seconds
>      [exec] *
>      [exec] * Please, refer to README.txt for details.
> 
> BUILD FAILED
> /localdisk/aapetren/harmony/build.xml:407: exec returned: 1
> 
> Total time: 7 minutes 45 seconds
> === cut ===
> 
> Will try to  find a solution.
> Any suggestions are welcome :)
> 
> SY, Alexey
> 
> 2008/1/17, Mark Hindess <mark.hindess@googlemail.com>:
> >
> > 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
> .com
> > > > 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@
> gmai
> > > l.co
> > > > > m> wrote:
> > > > > > > > Folks,
> > > > > > > >
> > > > > > > > We did a few iterations refactoring the subject -
let's have on
> e mo
> > > re a
> > > > > ccess
> > > > > > > > ;).
> > > > > > > > Why? There was a desire to have the following:
> > > > > > > > 1) More fine-grained control over dependencies to
empower modul
> arit
> > > y;
> > > > > > > > 2) Unified approach and shared scripts across Harmony
modules -
>  VMs
> > > ,
> > > > > > > > classlib, jdktools;
> > > > > > > > 3) Reduce duplication of resources (traffic, space,
etc) betwee
> n
> > > > > > > > modules within the same workspace;
> > > > > > > > I'd also add 4) If possible, reuse resources in different
works
> pace
> > > 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
>  wee
> > > ks
> > > > > > > back which I think was something like:
> > > > > > >
> > > > > > > 5) Move binary dependencies - like all the icu libs - from
the en
> hanc
> > > ed
> > > > > > > to the standard tree in svn and download them via http
as we do o
> ther
> > > > > > > dependencies during the fetch-depends stage.
> > > > > >
> > > > > > +1. Checking out tens of megabytes of unrelated binaries is
really 
> anno
> > > 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