You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/02/21 14:49:59 UTC
classlib ant clean is incomplete
I'm a unix hacker used to working at the command line. (But that
wasn't supposed to be a confession and I'm sure some of this will be
visible to IDE users.) When preparing patches, for example for the
the native-src, I might run:
cd native-src
ant clean
svn stat
to see what files I've added and/or removed. (Obviously I could use
svn diff but that only really answers the changed files question.)
At the moment when I do this I see:
? linux.IA32/build.log
? linux.IA32/include/unicode
? linux.IA32/text/libicuuc.so.34
? linux.IA32/vmi/vmi.map
? linux.IA32/fdlibm/e_exp.c
? linux.IA32/fdlibm/s_finite.c
... [ 100+ lines removed ]
? linux.IA32/zlib/adler32.c
? linux.IA32/zlib/old
? linux.IA32/zlib/amiga
? linux.IA32/zlib/infback.c
? linux.IA32/zlib/examples
(Aside: build.log should go soon I think. And one of my JIRA patches
fixes the clean target of the makefile that creates vmi/vmi.map.)
It's plain to see why most of these files are still around since, in
native-src/build.xml, make-all and layout have corresponding clean
targets but overlay-oss does not.
Of course, this is slightly non-trivial to fix since you can't easily
reverse the unzip. (You'd want an zip-content-list task that could be
used to create a fileset for a delete task.)
However, I think it's actually a good idea to do more to distinguish
the files that come from the two zip files anyway - for instance so
that people don't edit them and have changes clobbered by the next
make. So I had a go at unzip'ing them to zlib/dist and fdlibm/dist
respectively. (This has the added advantage that it is easier to
maintain svn:ignore properties for two directory entries than for the
dozens of files they contain individually.)
On Linux this was straightforward since GNU make supports VPATH. I'm
not really familiar with nmake on Windows but when I tried the same
syntax it failed. Does anyone know what options we might have for a
similar fix for Windows? One option is moving to GNU make on Windows
but that's a relatively big step?
I'd like to help completing this tidying up and the related exercise
of determining appropriate svn:ignore properties (so you don't *have*
to do "ant clean" before using "svn stat").
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: classlib ant clean is incomplete
Posted by Mark Hindess <ma...@googlemail.com>.
On 21/02/06, Tim Ellison <t....@gmail.com> wrote:
>
> Mark Hindess wrote:
> >
> > However, I think it's actually a good idea to do more to distinguish
> > the files that come from the two zip files anyway - for instance so
> > that people don't edit them and have changes clobbered by the next
> > make. So I had a go at unzip'ing them to zlib/dist and fdlibm/dist
> > respectively. (This has the added advantage that it is easier to
> > maintain svn:ignore properties for two directory entries than for the
> > dozens of files they contain individually.)
>
> I agree -- can you send the ant script / makefile changes via JIRA please?
Done.
> > On Linux this was straightforward since GNU make supports VPATH. I'm
> > not really familiar with nmake on Windows but when I tried the same
> > syntax it failed. Does anyone know what options we might have for a
> > similar fix for Windows? One option is moving to GNU make on Windows
> > but that's a relatively big step?
>
> How about changing references to foobar.obj to dist/foobar.obj in the
> windows makefile? I know is is not quite as cool as VPATH, but then we
> can lay out the files in the same way while we continue the discussion
> of sharing multi-platform code.
Agreed.
> > I'd like to help completing this tidying up and the related exercise
> > of determining appropriate svn:ignore properties (so you don't *have*
> > to do "ant clean" before using "svn stat").
>
> I'd like you to help do that too ;-)
;-) Submitted to JIRA.
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: classlib ant clean is incomplete
Posted by Tim Ellison <t....@gmail.com>.
Mark Hindess wrote:
> I'm a unix hacker used to working at the command line. (But that
> wasn't supposed to be a confession and I'm sure some of this will be
> visible to IDE users.) When preparing patches, for example for the
> the native-src, I might run:
>
> cd native-src
> ant clean
> svn stat
>
> to see what files I've added and/or removed. (Obviously I could use
> svn diff but that only really answers the changed files question.)
>
> At the moment when I do this I see:
>
> ? linux.IA32/build.log
> ? linux.IA32/include/unicode
> ? linux.IA32/text/libicuuc.so.34
> ? linux.IA32/vmi/vmi.map
> ? linux.IA32/fdlibm/e_exp.c
> ? linux.IA32/fdlibm/s_finite.c
> ... [ 100+ lines removed ]
> ? linux.IA32/zlib/adler32.c
> ? linux.IA32/zlib/old
> ? linux.IA32/zlib/amiga
> ? linux.IA32/zlib/infback.c
> ? linux.IA32/zlib/examples
>
> (Aside: build.log should go soon I think.
Done, removed in repo revision 379496.
> And one of my JIRA patches
> fixes the clean target of the makefile that creates vmi/vmi.map.)
>
> It's plain to see why most of these files are still around since, in
> native-src/build.xml, make-all and layout have corresponding clean
> targets but overlay-oss does not.
>
> Of course, this is slightly non-trivial to fix since you can't easily
> reverse the unzip. (You'd want an zip-content-list task that could be
> used to create a fileset for a delete task.)
>
> However, I think it's actually a good idea to do more to distinguish
> the files that come from the two zip files anyway - for instance so
> that people don't edit them and have changes clobbered by the next
> make. So I had a go at unzip'ing them to zlib/dist and fdlibm/dist
> respectively. (This has the added advantage that it is easier to
> maintain svn:ignore properties for two directory entries than for the
> dozens of files they contain individually.)
I agree -- can you send the ant script / makefile changes via JIRA please?
> On Linux this was straightforward since GNU make supports VPATH. I'm
> not really familiar with nmake on Windows but when I tried the same
> syntax it failed. Does anyone know what options we might have for a
> similar fix for Windows? One option is moving to GNU make on Windows
> but that's a relatively big step?
How about changing references to foobar.obj to dist/foobar.obj in the
windows makefile? I know is is not quite as cool as VPATH, but then we
can lay out the files in the same way while we continue the discussion
of sharing multi-platform code.
> I'd like to help completing this tidying up and the related exercise
> of determining appropriate svn:ignore properties (so you don't *have*
> to do "ant clean" before using "svn stat").
I'd like you to help do that too ;-)
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.