Geir Magnusson Jr wrote:
Oliver Deakin wrote:
Geir Magnusson Jr wrote:
Oliver Deakin wrote:
Geir Magnusson Jr wrote:
On thing to think about (which I didn't realize until now) is that
HDK should sit above /classlib in the tree right? the VMs will
need it as well. I imagine :
enhanced/
classlib/
drlvm/
jchevm/
bootvm/
So maybe add a
enhanced/common
directory in which the HDK sits by default?
I'd like to avoid the structural balkanization of making classlib
an island.
I had imagined that HDKs would be packaged up as zips and made
available
in a similar way to snapshots, rather than having a tree of
binaries checked into
SVN.
I think we all did. I don't know what about the above leads you to
assume I would have wanted this in SVN.
I think I'm just easily confused ;)
So are you suggesting that the HDK should sit in a concrete location
relative to whichever component (VM/classlib) we are working on, or
that the HDK zips should be stored in SVN? (or something else...?)
I think that the HDK should be a zip/tar that you download from our
distro locations(s), and dropped into
a) a well-known default location
b) anywhere you want so you can set a pointer if you have more than one
and no, they aren't stored in SVN.
Sounds good!
IMHO keeping it as a zip makes unpacking it where you want very
simple,
allows you to easily keep a "known good" HDK configuration locally
(in the
form of the original zip) and makes it very easy to get previous
versions of
the HDK (just download an earlier zip).
I'd be interested to hear what general consensus on this matter is,
and
how mailing list members would prefer the HDK to be provided.
Keeping zips around and all that is great, but is it that Eclipse
would break having it up and above the root of the project tree?
I dont see this as a problem.
If you use the Ant scripts to build (which can be used within
Eclipse), then
an hy.hdk property (described in one of my other mails in this
thread) that
can be set to point at an HDK will enable you to use any location.
If you wanted to work on Java code as a Java project under Eclipse,
then you should only have to point Eclipse at the jre under your HDK
and Eclipse will build against it.
Cool
Regards,
Oliver
geir
We discussed [1] that having separate HDKs for each VM and for
classlib
makes sense - as long as we keep them in a uniform shape, then they
can easily
overlaid onto each other to allow a developer to work on the
classlib and the
VM of their choice.
I don't see this separation of classlib and VMs as a bad thing. I
think that
having a VMI enabling us to develop the classlib and VMs as
distinct units,
and developing using potentially disparate methods and build
systems that
most suit that component, is one of the cool things about Harmony!
Regards,
Oliver
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED]
geir
Oliver Deakin wrote:
Hi all,
I have opened HARMONY-485, which proposes an additional doc for
the website describing the HDK and its contents.
The layout of the HDK described in the doc matches that produced
by the build script alterations raised in
HARMONY-469.
I hope that eventually (once the natives are modularised
and build scripts are altered to understand/use the HDK) the doc
will expand into a more full description of how developers can
use the HDK to rebuild Java/native code.
Regards,
Oliver
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
