2008/1/9, Mark Hindess <[EMAIL PROTECTED]>: > > On 9 January 2008 at 19:07, "Alexey Varlamov" <[EMAIL PROTECTED]> wrote: > > Folks, > > > > We did a few iterations refactoring the subject - let's have one more access > > ;). > > Why? There was a desire to have the following: > > 1) More fine-grained control over dependencies to empower modularity; > > 2) Unified approach and shared scripts across Harmony modules - VMs, > > classlib, jdktools; > > 3) Reduce duplication of resources (traffic, space, etc) between > > modules within the same workspace; > > I'd also add 4) If possible, reuse resources in different workspaces. > > This would be quite handy for committing purposes and for > > multi-platform development. > > I like all of the above but would add Tim's suggestion from a few weeks > back which I think was something like: > > 5) Move binary dependencies - like all the icu libs - from the enhanced > to the standard tree in svn and download them via http as we do other > dependencies during the fetch-depends stage.
+1. Checking out tens of megabytes of unrelated binaries is really annoying! > > A nice-to-have but not necessarily essential for a first approximation: > > 6) Ability to re-use system installed versions of dependencies - both at > build time and ideally at run time if the dependencies are stable. For > instance, my machine already has the 8 megs of dejavu fonts installed > (because openoffice uses them). I fool the build in to using them to > avoid the download but this should be made easier. At build time they > [a subset actually] are copied into the runtime and it might be nice > to avoid this if possible - although this part is easier to workaround > during debian/rpm packaging. Agree. > > > Geir once introduced "common_resources" module, which IMO was a step > > in the right direction, but it was not fully adapted thus not used > > properly. Now the new build for DRLVM is a good stimulus and > > opportunity to accomplish the task. > > > > I suggest this time we deprive the classlib of it's state of Harmony > > umbilicus and make the "common_resources" a "primordial" module ;) > > Does this mean the: > > svn co http://svn.../classlib/trunk classlib > cd classlib > ant fetch-depends > ant > > use case will cease to work? It would be nice if we didn't have to > break this. Perhaps we can have a classlib/trunk/common_resources > placeholder and if a h(armon)y.common.resources properties is not defined > then svn switch this placeholder to the correct copy (in a similar > manner to the way the federation build works). Well, I anticipated this point. The main issue here is locating properties.xml: IMO we should have a sole master copy of it, unlike current duplicates in classlib, jdktools and common_resources. It should be possible to avoid direct import of properties.xml in classlib/build.xml and rely on "fetch-depends" to check out common_resources if needed. But it looks a bit ugly to me, and probably will not preserve all current usecases? > Users will multiple work > spaces (or the federation build.xml) could set the hy.common.resources > property to a shared copy? Yes. > > > The idea is to move all shared properties, definitions, tasks and > > files to the single location. Besides, the same module should be used > > as a central repository for downloading and storing external files. > > So, each module would "request" needed resources via standard > > facilities (ant tasks), automatically reusing duplicates. And the same > > "common_resources" instance can be imported to several workspaces and > > even shared between developers. > > > > How? > > 1) Roughly, the following files need to be moved from classlib to > > common_resources: > > make/properties.xml > > make/depends.properties # ? move only shared items to > > simplify maintenance > > depends/** except depends/files/ # ? there are several libs/zips + > > make definitions being shared > > As I mentioned above, I think the platform specific files should > be moved to the standard (not enhanced tree) for download with > fetch-depends or whatever replaces it. And we should create the > bcprov-noidea.jar in the standard tree rather than downloading it from > bouncycastle to comply with their request to reduce load on their > servers. Sure, would be nice to document this as a guideline somewhere. And this can be done in parallel to other build refactoring, feel free to volunteer :) > > Closer comparison of other make/build-*.xml ant scripts in classlib > > and jdktools may give more candidates. > > 2) Implement tasks or macros for fetching resources, storing them and > > providing uniform access: common_resources/download.xml svn.xml etc > > 3) Refactor make/depends.xml in respective modules to resolve bullet #1. > > > > Surely the plan is very sketchy, we need to agree on general direction > > first. > > Waiting for your comments/objections impatiently :) > > Thanks very much for kicking off this discussion. Hope it will yield some material fruits this time... -- Alexey > > -Mark. > > > >
