harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [build] managing external dependencies
Date Wed, 09 Jan 2008 15:40:11 GMT

On 9 January 2008 at 19:07, "Alexey Varlamov" <alexey.v.varlamov@gmail.com> 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.

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.

> 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

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).  Users will multiple work
spaces (or the federation build.xml) could set the hy.common.resources
property to a shared copy?

> 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

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


View raw message