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: Supporting working on a single module?
Date Wed, 07 Jun 2006 16:03:38 GMT

On 7 June 2006 at 10:52, Geir Magnusson Jr <geir@pobox.com> wrote:
> Mark Hindess wrote:
> > On 7 June 2006 at 9:42, Geir Magnusson Jr <geir@pobox.com> wrote:
> >> Oliver Deakin wrote:
> >>> Just thought Id give a bit of a heads up on HARMONY-561.
> >>> The patch attached to that JIRA moves the header files under the
> >>> native-src/<platform>/include directories into
> >>> /modules/<luni|archive>/src/main/native. It also updates the build
> >>> scripts and
> >>> makefiles to move the headers into a shared location (<hdk>/include,
> >>> described at [1])  and compile against their new location.
> >> Right, and I really don't like it, have been saying I don't like
> >> overwriting the HDK, gave a reason for why I don't like it, and never
> >> heard a reason why it must be this way.
> > 
> > It's no different to how we've been deploying java code for the last
> > several months. 
> Sure it is, if you think of the HDK as a binary snapshot you can build
> against.
> > That is, if you build at the top level, you are
> > effectively creating the java parts of the jre (which is part of the
> > large hdk).  If you then go and build in say modules/luni, you are
> > building against the jars in the "hdk/jdk/jre/lib/boot" directory and
> > the new luni.jar will be overwrite the existing one.
> That's misleading, because there is no 'hdk' now.
> There's nothing wrong with having a /deploy or /target directory that we
> build into in parallel w/ the hdk, and no one's told me why that's a bad
> idea, since *that* is how we've been working for several months now.

Ok.  This is all Oliver's changes are doing - building native code into
/deploy?  So your objection is that we are calling this directory the
hdk?  When the hdk should be an artifact that we just keep zipped up
and unpack (possibly as part of the build) to deploy before building
anything that overwrites it?  (This has the advantage that we don't have
to change the launcher.)

> Remember, the motivation for this change is to modularize the natives,
> not the hdk. lets not let the tail wag the dog here.
> > So if Oliver is breaking anything by these changes, then it is
> > nothing that wasn't broken before for the java code building
> > process.  So I don't see the harm in proceeding because without this
> > or something like it, it is impossible to move forward with (long
> > overdue) the native-src restructuring.
> I don't think I said he was breaking anything.  I said that I felt
> that any alternatives that I suggested that got us to the same place,
> yet in what I felt lead to clarity and diversity in use case were
> ignored.
> Isn't anyone else bothered by the build process dropping artifacts
> into and overriding what is an SDK?

I think I understand why someone might be bothered but I'm not really

If I want a pristine copy back I just unzip it again.  I don't see
the immediate benefit of keeping a pristine copy unzip'd.  The only
advantage I see that comes from not changing the unzip'd copy would
be that you could have just one unzip'd pristine copy.  But without
changing the launcher (and complicating things for every user not just
developers) I don't see how you could use a single copy, unless you copy
it which would negate this advantage.

> > No one has felt a pressing need to solve the problem with respect to
> > the java code parts of the hdk (jre) being overwritten so I don't
> > see why we now need to solve that problem first.
> You are mixing two things up here.  No one cares if we overwrite
> stuff in the build destination - that's a necessity - and that's not
> the issue.  The issue is confusing the hdk, something that we'll
> distribute as snapshots or versioned releases, w/ the build target.

Ok.  Let's stop calling what Oliver is doing an hdk then.

> >> If you want me to put my money where my mouth is and just patch
> >> it, I'm more than able to do that, but I'd rather reach consensus
> >> together on how to go forward.
> >
> > I'd prefer the consensus approach too.
> >
> > Having said that I am interested in how you would patch it.  I've
> > not clearly understood how it should be solved/patched.  Ignoring
> > the native code for a moment, how do you propose to solve the
> > problem with respect to the hdk/jdk/jre/lib/boot jars?  Where should
> > the jars go when we build at the top level?
> /target/jdk/jre/lib/boot for example
> <aside>
> ...and to be honest, I think that it should be in a peer to /classlib,
> not inside of clsaslib.
> ... and which the word 'target' up for debate, although I prefer it to
> 'deploy', because I think of deploy as a tree created when you push the
> button to do a release or snapshot.... i.e.
>   /deploy/harmony-0.5-snapshot/....
> </aside>

I do think we should consider how we are using these names.  I notice
that the Apache Commons projects that I was looking at recently use
build (or sometimes target) for the build artifacts and dist for the
sense in which you think of deploy.

> >  Currently they go in the hdk - just as they always have - except we
> > didn't call it that.
> I think that's a really deceptive argument, as the hdk is more
> than just a simple directory rename.  It's a distributed versioned
> resource.

Then I think it's fair to say what Oliver is doing isn't that (at least
not yet!) and more importantly what he is doing isn't preventing us
creating a real hdk in future.  Or am I missing something?

> >  Where do you think we should put the jars created when we build in
> > a module?
> Where they went before
> >Should the launcher be modified to support looking for the jars
> >in all locations (with the hdk/jdk/jre/lib/boot location as last
> >resort)?
> Well, I believe we still have to sort out where we think that the hdk
> lives, given classlib is just one part of Harmony.  (I know we've
> been very focused on the classlib until now, but our goal is JavaSE,
> not a classlib) But putting that aside, yes, that's sortof what I was
> imagining although I didn't quite grok the best way... I don't know
> if it's possible, creating classpaths and library paths that are a
> combination of the /target stuff in front of the /hdk stuff, so that
> you can 'override'...
> So let me try to summarize my objections - my main objection is that
> while I agree the hdk is a powerful and useful idea, we're mixing
> up the hdk and the build destination, for reasons that haven't been
> explained.

I think the only thing we are doing wrong is calling it the hdk when
really it is a collection of build time artifacts, not really different
from the jars, that might in future be packaged up to form an hdk for
distribution to developers.

Possibly they will be packaged up with the build artifacts of a vm
build.  However, I personally prefer to keep the hdk artifacts separate.
(Arguably they would only be components of a complete hdk in this case.)
Since the hdk artifacts are for developers and I'd like to encourage
developers to use one classlib hdk (we are only doing one? ;-) but to
consider using more than one vm hdk for development and testing.

Probably I'd package up jdk in the traditional way.  (Even though the
launcher enables us to package more than one vm with classlib, of


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message