As the Harmony Classlib grows, I think that being able to work on a single module (or some subset of the modules) will become the typical way of working for many (perhaps even most) contributors. So I think we need a plan to support this. I also think that forcing ourselves to support this mode of working sooner rather than later will help us keep from accidentally breaking the modularity in the current build/development process.
Oliver is currently looking at restructuring the native source to the appropriate modules/*/src/main/native directory. One question that comes out of this investigation is: where should the include files "live"? I think they belong with the module that provides the implementation defined by the declarations in the header. That is, zipsup.h is "owned" by archive, hythread.h is "owned" by thread (luni), etc. However, if the build was to refer to the header files within the modules then this breaks the modularity. So, for example, someone working on a single module would have to checkout all the dependent modules rather than just the one they wish to work on. So, perhaps, at build time we should copy the header files out of the owning module into a common include directory. All modules would then refer to the header file in the common include directory. This means we can then create a snapshot tar/zip of the common include directory which someone wishing to work on a single module could download to build against. This is not dissimilar to the current way in which you could build the java sources against a deploy/jre snapshot. For windows, the snapshot would also include the .lib files that are required to build for the run-time .dll files. What is this new snapshot? Well, Tim suggested that it was a little like the jdk but for Harmony development. So perhaps it should be called an hdk, Harmony Development Kit? Logically, in the same way that a jdk contains a jre, the hdk should contain the jdk (which will contain the jre). Thus, we'd have a hierarchy like: deploy/hdk deploy/hdk/jdk deploy/hdk/jdk/jre When we come to create snapshots/releases, it's easy to see how we'd create archives for the hdk, jdk, and jre. Unfortunately, though I think this solution is quite elegant, there are quite a few references to the "deploy/jre" path that would need to be fixed. However, I think this is something we should discuss and, if we decide it is the right thing to do, then we should take the hit and move things around now. What do you think? Regards, Mark. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
