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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
