[general] /harmony/enhanced/java/branches/mrh

[Tim Ellison <t....@gmail.com>]

Mark,

The "mrh" branch has been around for a while, can you share your plans
for it?

I realize you 'went off' for a while to do some restructuring, but from
what I can tell most of that work was merged back to the main line already.

I'd like to ensure we keep these temporary branches, well, temporary!

Regards,
Tim

Re: [general] /harmony/enhanced/java/branches/mrh

[Mark Hindess <ma...@googlemail.com>]

In message <AA...@mail.gmail.com>,
Catherine Hope writes:
> 
> Hi Mark,
> 
> I've noticed that the source and tests for all the tools under
> jdktools/modules/jretools is duplicated under jdktools/modules/jdktools
> since a merge from the mrh branch, e.g. there's a keytool under:
> jdktools/modules/jretools/src/main/java/org/apache/harmony/jretools/keytool
> and
> jdktools/modules/jdktools/src/main/java/org/apache/harmony/tools/keytool

"since a merge from the mrh branch"? which commit exactly? what revision
number?  Are you sure something changed as a result of a merge from my
temporary branch?


I don't recall anything significant changing in this area since:

  r702139 | hindessm | 2008-10-06 13:55:28 +0100 (Mon, 06 Oct 2008) | 3 lines

  Initial split of jdktools to jdktools and jretools.  There is still
  work to be done to fix the duplicated classes that are in both.

I don't recall why the duplication was needed to help make the split but
I imagine it is something to do with resolving the dependencies either
at build time or at runtime - the classpath setup in the samsa launcher
is pretty ugly.

Anyway, it looks like the work to fix it still needs to be completed.
There is probably an entry on my todo list for it.

> Is this part of the on-going restructuring?

Not intentionally so.

-Mark.

Re: [general] /harmony/enhanced/java/branches/mrh

[Catherine Hope <ca...@googlemail.com>]

Hi Mark,

I've noticed that the source and tests for all the tools under
jdktools/modules/jretools is duplicated under jdktools/modules/jdktools
since a merge from the mrh branch, e.g. there's a keytool under:
jdktools/modules/jretools/src/main/java/org/apache/harmony/jretools/keytool
and
jdktools/modules/jdktools/src/main/java/org/apache/harmony/tools/keytool

Is this part of the on-going restructuring?

Best wishes,
Cath

Re: [general] /harmony/enhanced/java/branches/mrh

[Mark Hindess <ma...@googlemail.com>]

In message <4C...@gmail.com>, Tim Ellison writes:
>
> Mark,
> 
> The "mrh" branch has been around for a while, can you share your plans
> for it?

Sure.  Thanks for asking.

There have been several items on my todo list for Harmony that have been
on the list for a number of years.  Specifically:

1) Consolidate the properties.xml/depends.xml from classlib and 
   common_resources to avoid the unnecessary duplication.  (This
   will mean that those using classlib only builds will need a
   common_resources checkout to pull in these files.)

2) Refactor the DRLVM code to:

   a) have similar structure to the other components

   b) use make to build the native code

3) Native dependency handling.  DRLVM used cpptasks so had good (but
   slow) dependency handling.  I don't want to lose this feature in the
   move to makefiles so I intend to update all native builds to support
   dependencies by generating them during compilation/preprocessing.

4) Isolate build artifacts.  DRLVM does this and again I don't want
   to lose this feature.  I intend to build all artifacts into
   target/build/{classlib,jdktools,drlvm}/<module>/{java,native,test}.
   In theory this should allow for a very fast clean step:

     rm -rf target/{build,hdk}

   so long as no exclude.module/build.module/build.java/etc options have
   been specified.

   DRLVM also uses a different directory for built artifacts
   depending on the os, compiler, etc.  I don't intend to be
   so prescriptive about it but I do want to support setting
   -Dhy.target=target.config{1,2,3,...} to allow for several builds
   (with different [vm.dir/hy.select/etc] configurations) in a single
   workspace without being forced to do a rebuild each time you switch
   configuration.

5) Consistent handling of built native dependencies.  For instance, zlib
   and fdlibm are cleaned by the clean target but apr is not.  The apr
   approach doesn't seem unreasonable given that these dependencies change
   infrequently but there should be a "distclean" target that also cleans
   these.

Item 1) is more or less complete to the point I could merge it back.  I
will try to do that - though it will mean those not using the federated
build to build classlib will need to set the common.resource property to
point to a suitable common_resources checkout - this has been the case
for those working in drlvm only for several years so I don't see this as
a problem but it is a change to the way of working.

I am part way through 2).  I have mostly restructured the native code
into modules/*/src/main/native/*.  I have also made the necessary
makefile changes for the unix builds.  I still have to do the equivalent
changes for the windows builds so they are currently completely broken
in my branch.  I've also not restructured the java code - though that
should be a somewhat simpler exercise that needn't be done in a branch.

(I am maintaining a script to process patches - e.g. from open
JIRA - against DRLVM so that they can still be applied after the
restructuring.)

Item 3) is complete for linux and I hope to do something similar while
I work on 2) for windows (though I wont gate the merging back on
completing this).

Item 4) is complete with the exception of some items in drlvm.  It is
complete enough to merge back.

Item 5) can be completed in trunk.

In short, I'll fix the drlvm windows native build then complete the
merging back and remove my branch.

> I realize you 'went off' for a while to do some restructuring, but
> from what I can tell most of that work was merged back to the main
> line already.

Indeed.  I had merged everything back at one point but I've made even
more changes since that point.

> I'd like to ensure we keep these temporary branches, well, temporary!

Maintaining branches is not a trivial matter (particularly not when
there are significant moves) so I certainly don't intend to maintain it
longer than necessary but sadly I've not had as much spare time to work
on this recently.  I will endeavour to make progress with it in the next
week or so.  (The linux "fresh" build time is reduced by more than 50%
on my machine so I think it has been worth the effort.)

Regards,
 Mark.