I think Oliver has made really good argument. Once I refactored out to common_resources quite a few duplicated build functions from drlvm and jdktools, but somehow did not gain enough momentum to push classlib in this direction - I guess people were reluctant to force dependency on federated build? I still think common_resources would be the best way to mitigate build maintenance efforts, even more so if extended with the vision Oliver's suggested.
Really I don't see why jdktools could get more attention if merged to classlib. OTOH, from VM development point of view I'd be bothered with extra build&test time of basic JRE. Surely this could be coped with via predefined module sets, but the point is lost then. Regards, Alexey 2009/7/23 Oliver Deakin <oliver.dea...@googlemail.com>: > Tim Ellison wrote: >> >> On 23/Jul/2009 09:43, Sean Qiu wrote: >> >>> >>> Do we really need this big change? >>> >>> There are so many "duplicated" xml files whose original goal is to >>> achieve modularity. >>> So each component can be developed and tested separately. >>> I guess that's the reason that we got so many build scripts on each >>> modules of classlib. >>> (It is another story whether they worked as we expected) >>> >>> I prefer to keep jdktools and classlib separately, it sounds more natural >>> to me. >>> >> >> My gut feeling is also to keep the class library and jdktools separated, >> but I'll admit that it is only a gut feeling and not something I can >> defend technically. >> >> If it really does make life easier for build then it is something I >> could learn to live with. I'd like to hear the arguments though. >> > > I agree. It just feels to me like the VM and classlib are obvious "units" > and putting the additional jre/jdk tools in with either one of them doesn't > sit right. If our goals are to get the jdktools used/looked at more and to > unify the build scripts as much as possible, then I would suggest improving > the federated build for wider use. > > At the moment if a contributor wants to just work on classlib, they will > probably just check out classlib trunk and build from there copying in > whichever VM they wish to use. I think it would be better if we made the > federated build the starting point for this kind of development and improved > the build targets it provides so it plays nicely when working with > individual components. For this to work we would need to allow more control > over what source gets checked out/built/tested, so they more closely reflect > the targets within the components - here's a few examples of what I was > thinking of (names like hy.component are just suggestions, not really > important): > > "ant -Dhy.component=classlib,jdktools populate-src" - just checkout the > source for classlib and jdktools > "ant -Dhy.component=classlib rebuild-native" - just clean and build the > native code for the classlib module, and automatically populate the built > binaries under the federated target directory > "ant build-java" - build java code across all components. This target could > detect which components have been checked out, much as the classlib build > works out which modules to build automatically by checking if build targets > exists, and only build those so that hy.component does not always need to be > specified. > > > The above is just a rough idea of how it could be done, but I can see a few > advantages of this approach: > 1) The federated build would get used more, giving us a more unified > approach to building Harmony while still allowing contributors to work in > individual areas with the same ease. This should also help remove some of > the build script duplication across components. > 2) The java/javaw executables could be moved to jdktools (which makes more > sense than classlib to me) meaning that jdktools would get more attention > also. > 3) The common_resources directory would work for those working on the whole > jdk and also for those just working on one or two components, as they would > both use the federated build. > 4) If we ever wanted to add components (for example, split portlib into it's > own component) it would be easier managed. > 5) If you started working on drlvm only and also wanted to make some changes > to classlib later on, you could just run populate-src specifying the > classlib component to check out the additional source and then carry on > working. > > These are just ideas at the moment, but I can see there are benefits to this > approach. Any thoughts/comments? > > Regards, > Oliver > >> Regards, >> Tim >> >> >> > > -- > Oliver Deakin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > >
