On 16 June 2006 at 11:48, Oliver Deakin <[EMAIL PROTECTED]> wrote: > 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. > > > > Agreed. A while back I opened HARMONY-286 (which was never applied, > and is likely wildly out of date by now) to create build-java and > build-natives targets in the main build.xml - I was spurred on by the > fact that the only way to compile only Java or only native code was > to go and run those particular Ant scripts, and there were errors in > the scripts that meant they couldn't be run standalone without some > tweaking (which I believe have since been fixed).
I think compiling native/java is less of an issue now we don't "clean"? What do you think? > It would be nice to get to a point where a developer can rebuild/test > any part of the classlib just by calling targets in the main > build.xml. > > > 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. > > > Perhaps we could also have the capability to build individual modules > by specifying "-Dbuild.module=luni"? Obviously this would rely on you > previously building the whole classlib (as the modular build would > require its dependencies to already exist) or have an HDK installed > somewhere. Some might argue that this would be better achieved by moving to the module level, but it could come out in the wash when fixing my "test-luni gen-report" issue so I don't see any problem with supporting 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. > > > > 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. > > > > Agreed - currently the extra Ant files under platform are of no use and > can safely be removed. > IMHO they won't become useful any time soon since, as you say, all we do > to build native code > is exec whichever make command. I dont think that justifies separate > platform specific scripts. > > Perhaps we could have Ant scripts organised in a similar way to those at > the top level? > i.e. the main build.xml is at the top level of the module. Then under > the module's make > directory we have a build-java.xml, a build-native.xml and a > build-tests.xml, which the top > level build.xml delegates all of the "real work" down to. As you > suggested above, the top level > build.xml contains all the common targets that a developer might want to > use, such as build-native, > clean-native etc. > > Sound good? I like as few layers of indirection as possible but agree that modules and top-level should be alike where possible. > > 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.] > > > > These files can be a little bit unreadable - are you suggesting > that we still have a separate properties file but it contains plain > one-line properties instead of xml, or get rid of the separate > properties file altogether and incorporate all the required properties > into whichever build script they are appropriate to? I was thinking still keeping a separate file. There might be an issue with some "location" variables since you can't distinguish between value and location properties in text files. (At least I don't think so but I could be wrong.) > > 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.) > > > > Do you mean the classes that are built under the > <classlib_trunk>/build directory? Since I've been doing work on > modularisation recently, I've been thinking about where modules should > build their classes when you run the module level build script. > > I was thinking about a developer who only had, say, luni checked out > and an HDK to build against. He goes into the luni module and runs > the main build.xml, but when this builds the Java code it tries to > stick the classes into <module_dir>/../../build, which doesnt actually > exist! I was wondering if maybe the default output dir for a modular > java build should be <module_dir>/build, and for a global build it > will be <classlib_trunk>/build? We had things building to two places before it caused really confusion. I think George would remember the details. > So can I suggest that the modular build.xml defaults to building and > cleaning its classes in a <module_dir>/build directory, but allow the > location of the build directory to be overridden? The first part is what I was suggesting but ... I think the overriding needs thinking about a little more. Specifically, I don't want someone doing: cd classlib ant cd modules/luni ant and having classes compiled to two different locations. But if modules/ luni is your "top-level" then yes, building to ../../build is a little odd. ;-) > > Well, these are some of the things that are bothering me. I suspect > > others have other issues? > > > > I also notice that the modular build.xml looks to open the > properties file in the classlib/trunk/make directory by > using a relative path from the location of the module i.e. > <module_dir>/../../make/properties.xml. If a developer only has > that module checked out, then this relative location will not work - > this is something that I guess can be approached if you rework the > properties files (5). I think there are a lot of issues when building with just one module checked out. I think we should fix the existing problems - but with this issue in mind - and deal with this on a new thread. -Mark. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
