In message <4c3447cc.9080...@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.
