harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject [build] managing external dependencies
Date Wed, 09 Jan 2008 13:07:40 GMT

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.

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 ;)
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.

1) Roughly, the following files need to be moved from classlib to
make/depends.properties               # ? move only shared items to
simplify maintenance
depends/** except depends/files/    # ? there are several libs/zips +
make definitions being shared
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 :)


View raw message