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 Re: [build] managing external dependencies
Date Wed, 16 Jan 2008 12:07:47 GMT
2008/1/9, Mark Hindess <mark.hindess@googlemail.com>:
>
> 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.

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

Mime
View raw message