I got the following error on federated build which looks as a result
of this change:
=== cut ===
[exec] -init-unix:
[exec] [symlink] ln -s
/localdisk/aapetren/harmony/working_classlib/depends/libs/linux.x86/icu-3.4/libicuuc.so.34
/localdisk/aapetren/harmony/working_classlib/depends/libs/linux.x86/icu-3.4/libicuuc.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 <[EMAIL PROTECTED]>:
>
> 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"
> <[EMAIL PROTECTED]> wrote:
> > Thanks, Mark!
> >
> > SY, Alexey
> >
> > 2008/1/16, Mark Hindess <[EMAIL PROTECTED]>:
> > >
> > > On 16 January 2008 at 15:53, "Alexey Petrenko" <[EMAIL PROTECTED]
> > > wrote:
> > > > 2008/1/16, Alexey Varlamov <[EMAIL PROTECTED]>:
> > > > > 2008/1/9, Mark Hindess <[EMAIL PROTECTED]>:
> > > > > >
> > > > > > On 9 January 2008 at 19:07, "Alexey Varlamov" <[EMAIL PROTECTED]
> > 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
> > > > > > > modularit
> > y;
> > > > > > > 2) Unified approach and shared scripts across Harmony modules -
> > > > > > > VMs
> > ,
> > > > > > > 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
> > > > > > > workspace
> > 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
> > > > > > enhanc
> > ed
> > > > > > to the standard tree in svn and download them via http as we do
> > > > > > other
> > > > > > 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.
> > >
> > >
> > >
> >
>
>
>
