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 <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
