I just sent a note with a subset of these same concerns! That's quite the laundry list ...
Mark Hindess wrote: > There are a couple of things I'd like to "fix" about the build.xml > structure. I'd be very interested in what other people think about > these issues. In no particular order: > > 1) Currently when you look at the classlib checkout for the first time > the first think most people are going to do is look for a build.xml > file. Well, we don't have one at the top level. Fortunately 'make' > is an obvious place to look but then you find several .xml files. > Again fortunately build.xml is the obvious choice but the other files > 'build-java.xml' and 'build-test.xml' might be confusing ... the latter > more especially when you come to run the tests. (Granted reading the > README helps.) > > I think we should move build.xml up to the top-level. > > It isn't the case right now, but we should aim to make this the only > ant file that developers need to invoke when building/testing at the > top-level. > > An example of why this doesn't quite work right now is that I > sometimes use make/build-test.xml with arguments like "test-archive > gen-report" to just run the tests for the archive module. Rather than > create test-archive, test-auth, etc in the top-level build.xml I think > we should us a variable so you can do "ant -Dtest.module=luni test" > rather than "ant test-luni gen-report". Obviously the default if the > variable is not set should be to test every module. This is not > dissimilar to the test.case variable usage in the module build.xml > files. > > I'm sure others can think of more examples. I think doing this helps > to make it clear which parts of the ant scripts are API - that we > should aim to support (and over time stabilise) - and which bits are > "internals" that might change. I just suggested the same thing, so yes. > 2) There is a similar issue at the module level and again I think we > should move the build.xml file up one level. (The API distinction at > this level is already pretty clear.) > > > 3) Currently the 'build' target automatically does a 'clean'. I think > this dependency should be removed and a new target - 'dist' perhaps? - > should be created for doing non-incremental builds. > > [Geir has already fixed the first part of this since I started writing > this.] > > > 4) Also at the module level, I think we should compress the two layers > of make/build.xml and make/common/build.xml. For one thing it is very > confusing, that: > > a) modules/auth/make/common/build.xml builds the platform-specific > java code, and > > b) modules/luni/make/platform seems to be related to what we've been > calling native code not about platform-specific java code. > > It would be crazy to separate building of platform-specific and > platform-independent java code because we'll only have problems > handling dependencies and it would mean a lot of duplication. The original intent was that there would be more variance in the native code that had to be handled this way; if we are not seeing it then great, simplify -- and we can address multi-platform concerns as we come across them. > Even if we renamed 'platform' to native, I still don't think the > separate build.xml is needed since all it would ever do - in the near > future when we start moving the native code - is call straight out to > a makefile (or configure or whatever) so I don't think this extra > layer would add much. > > > 5) The module ant files use a properties file to define a bunch of > variables called: > > hy.<module-name>.blah.blah > > Is anyone really attached to xml properties files? Personally I find > it much easier to read text properties like: > > hy.luni.src.main.java=src/main/java > hy.luni.bin.main=bin/main > > than: > > <hy> > <luni> > <src> > <main> > <java location="src/main/java" /> > </main> > </src> > <bin> > <main location="bin/main" /> > </bin> > </luni> > </hy> > > [Aside: hy.luni.bin.main isn't used (correctly) any more anyway.] I really don't have a problem reading them, but whatever. I thought there were places where it was not just locations that were being defined, but jar names etc? I don't really mind either way. > 6) Mikhail (IIRC?) modified a few of the module build files to use > macros. I like this idea (in fact one of my earlier abandoned JIRAs > took it quite a bit further) because it helps to hide the less > important details of what is going on away from the important ones - > in the case of the modules leaving only differences between modules. As long as I can understand what is happening with a quick glance -- let's not get 'clever' ;-) > 7) The init targets in each module build.xml don't really contribute > anything to the build. Does anyone really read the output they > generate? No. > 8) Running "ant -f make/build.xml" from a module sub-directory doesn't > actually clean the main compiled classes. (I think this is pretty > important to getting consistent expected behaviour so I'm looking at > this right now and will fix it shortly unless anyone shouts.) > > > Well, these are some of the things that are bothering me. I suspect > others have other issues? Related to the build or in general :-p ? I'd like to be able to download dependencies from the top-level script too, so svn co ... cd ... ant get-depends (or whatever) ant (builds everything) ant test and you are done. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
