harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Beliaev" <vladimir.k.beli...@gmail.com>
Subject Re: [build] jdktools skips a fetch-depends for federated build
Date Fri, 19 Oct 2007 16:58:43 GMT
2007/10/19, Mark Hindess <mark.hindess@googlemail.com>:
>
>
> On 19 October 2007 at 15:22, "Vladimir Beliaev" <
> vladimir.k.beliaev@gmail.com>
> wrote:
> >
> > Hello, Mark,
> >
> > > ant -Dauto.fetch=true
> > >
> > > It should work if you do this?
> >
> > I've missed this. Thanks a lot for the note.
> >
> > > seem overly complicated and probably can be replaced by a single
> > > target:
> >
> > Yes, until this "inheritall="false"" is inserted not just for fun...
>
> Sorry, I don't understand.  I suggested replacing two:
>
> <ant inheritall="false" .../>
>
> calls with a single:
>
> <ant inheritall="false" .../>
>
> call so I don't see the problem.  Can you explain what you think I've
> missed?


I do not see the problem too. I've missed inheritall="false" in first tag.

Looking at the similar calls for classlib_fetch_depends I see that
> what is actually wrong is that the "fetch_jdktools_libs" target is not
> supposed to have the if="auto.fetch" attribute.  (It is supposed to be
> unconditional so a user can invoke it.)  This is an excellent example of
> why it is helpful to see which tasks are supposed to be called by a user
> and which are not.
>
> > > For example adopting the convention of beginning non-api/-user
> > > targets with hyphen so it is easier to read
> >
> > Yes, code clean up work is really fun especially for one who is able
> > to commit it immediately...
>
> I'll reply to this in another note but, assuming I understand you
> correctly, the short version is "I strongly disagree".


I believe your assumption is not correct. Looks like my phrase is confusing.
Sorry.

Thanks
Vladimir

Regards,
Mark.

> 2007/10/19, Mark Hindess <mark.hindess@googlemail.com>:
> >
> >
> > For licensing reasons, fetch depends is only executed if you run:
> >
> > ant -Dauto.fetch=true
> >
> > It should work if you do this?
> >
> > Having said that I think there is room for improvement in the build.xml.
> > For example, these targets:
> >
> >    <target name="auto_fetch_jdktools_libs" if="auto.fetch">
> >        <ant target="fetch_jdktools_libs" inheritall="false" >
> >            <property name="hy.cfg" value="${hy.cfg}"/>
> >        </ant>
> >    </target>
> >
> >    <target name="fetch_jdktools_libs" if="auto.fetch">
> >        <ant antfile="working_jdktools/build.xml" target="fetch-depends"
> > inheritall="false" >
> >            <property name="hy.cfg" value="${hy.cfg}"/>
> >        </ant>
> >    </target>
> >
> > seem overly complicated and probably can be replaced by a single target:
> >
> >    <target name="auto_fetch_jdktools_libs" if="auto.fetch">
> >        <ant antfile="working_jdktools/build.xml"
> >             target="fetch-depends" inheritall="false" >
> >            <property name="hy.cfg" value="${hy.cfg}"/>
> >        </ant>
> >    </target>
> >
> > Unless I'm missing something?  This build.xml really needs some cleanup.
> > (For example adopting the convention of beginning non-api/-user targets
> > with hyphen so it is easier to read.)  Maybe I'll take a look later.
> >
> > Regards,
> > Mark.
> >
> > On 19 October 2007 at 12:06, "Vladimir Beliaev" <
> > vladimir.k.beliaev@gmail.com> wrote:
> > >
> > > Hello,
> > >
> > > I come across the same issue twice - the federated build skips
fetching
> > > dependencies for jdktools.
> > >
> > > I mean I did a build just by simple 'ant' command from the root
> > directory of
> > > federated workspace:
> > >
> > > /tmp/trunk $ pwd
> > >     /tmp/trunk
> > >  /tmp/trunk $ ls -1
> > >     working_classlib/
> > >     working_jdktools/
> > >     working_vm/
> > >     <skipped>
> > >  /tmp/trunk $ ant
> > >      <skipped>
> > >     BUILD FAILED...
> > >      <skipped>
> > >
> > > And this can be fixed by:
> > >
> > >  /tmp/trunk $ cd working_jdktools
> > >  /tmp/trunk/working_jdktools $ ant fetch-depends
> > >
> > > Is it a known issue?
> > >
> > > I double check trunk/build.xml - looks like all tags for jdttools's
> > > fetch-depends are in place... So it may be my local issue... That's
why
> > > I ask.
> > >
> > > --
> > > Vladimir Beliaev
> > > Intel Middleware Products Division






-- 
Vladimir Beliaev
Intel Middleware Products Division

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