'and -Dauto.fetch' is a working way to create a federated build

[Alexei Fedotov <al...@gmail.com>]

Hello,

Since my May trip I used hand-made scripts [1] to fetch dependencies
and people around couldn't told me why simple 'ant' no longer worked.
Today I've discovered this option and then the explanatory thread
below.

This might be useful for somebody as well.

[1] for d in common_resources working_classlib working_jdktools; do (
cd $d; ant fetch-depends && ant ); done && ( cd working_vm; cd build
&& ./build.bat update && ./build.bat && ./build.bat test2 )

On 5/14/07, Stepan Mishura <st...@gmail.com> wrote:
> On 5/10/07, Stepan Mishura wrote:
> > On 5/8/07, Tim Ellison wrote:
> > > Stepan,
> > >
> > > The 'fetch-depends' has to stay as a separate target invoked explicitly
> > > by the user.  It can't be part of the default action. That is where we
> > > may download code whose licenses falls under the binary-only category
> > > (like ECJ) as described here [1].  Of course, we can continue to check
> > > for the existence of the dependencies by default.
> > >
> >
> > Tim, thanks for the note. Actually, I fixed it by analogy with
> > classlibrary and drlvm (for example, see build_classlib target) - the
> > federated build fetches theirs dependencies automatically. Yes,
> > according to [1] we have to fix the federated build ... and CC scripts
> > too (currently CC fetches dependencies automatically by defualt.)
> >
> > I think we should add to builds new option, say 'fetch-automatically'
> > (it is set to 'false' by default.). And the option should be added to
> > classlib, drlvm and jdktools builds.
>
> I've removed external code downloading as default action. And
> 'auto.fetch' option was added to federated build to make it possible
> to automate downloading.
>
> Thanks
> Stepan.
>


-- 
With best regards,
Alexei,
ESSD, Intel