You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/05/23 20:32:32 UTC
Multi-tree HDK config - working directory ( was Re: Supporting working
on a single module?)
Some stuff that got lost (because I got consumed by J1 and I was the
only one pushing on it) was the idea of ensuring that
1) the HDK could be anywhere - the was no hard-wired spot. That allowed
having multiple simultaneous HDKs (ex different snapshot version) at the
same time as a full build
2) the build should ensure that the materials of the HDK never get
overwritten so that we can always tell a contributor w/ a question
"first, before we debug this, do a ant hdk-copy.." or something to
easily get them to a known good state.
This to me sounds like we need some kind of working directory and a
'hdk-copy' target.
The working model then allows freedom of choosing an hdk or a current
full build as the 'base' to work with...
Does this make any sense to anyone else?
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Multi-tree HDK config - working directory ( was Re: Supporting
working on a single module?)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Oliver Deakin wrote:
> Geir Magnusson Jr wrote:
>> Some stuff that got lost (because I got consumed by J1 and I was the
>> only one pushing on it) was the idea of ensuring that
>>
>> 1) the HDK could be anywhere - the was no hard-wired spot. That
>> allowed having multiple simultaneous HDKs (ex different snapshot
>> version) at the same time as a full build
>
> Perhaps the HDK would have a default location which could be overridden
> by passing a command line option to the build scripts - possibly in a
> similar
> way to Marks suggestion for selection of the rmi module location [1].
Yea, but the RMI thing is hopefully going to go away, right? :)
> My modifications to build an HDK from the classlib code (HARMONY-469)
> use an Ant property hy.hdk to specify the root directory of the HDK. With
> the current patch, this property doesnt quite propagate all the way down
> to the native makefiles, but this shouldnt be too hard to extend. Once this
> was done, a developer could then override the default HDK location using
> a command line similar to:
> ant -Dhy.hdk=/my/hdk/location -f make/build.xml
>
>
> The default HDK location would probably depend on what area you are working
> on - in classlib the trunk/deploy directory is the default build
> location at the
> moment, and I think it makes sense to keep this as the default HDK
> directory.
That seems to work.
>
>>
>> 2) the build should ensure that the materials of the HDK never get
>> overwritten so that we can always tell a contributor w/ a question
>> "first, before we debug this, do a ant hdk-copy.." or something to
>> easily get them to a known good state.
>>
>> This to me sounds like we need some kind of working directory and a
>> 'hdk-copy' target.
>>
>> The working model then allows freedom of choosing an hdk or a current
>> full build as the 'base' to work with...
>
> I imagine that an HDK would come in a zip format, much like the current
> snapshots [2].
> If this was the case, then once you have downloaded the HDK zip, you can
> unpack it
> into your working directory where it will be modified. However, you
> still have the
> original zip to fall back on if you need to. I'm not sure that we need
> an extra build
> target for this process - to get back to a known good state, you can
> just unpack the
> zip again into your working directory.
>
> Am I missing something?
Yah.
>
> Regards,
> Oliver
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c200605240628.k4O6S6TX002666@d06av02.portsmouth.uk.ibm.com%3e
>
> [2] http://people.apache.org/dist/incubator/harmony/snapshots/
>
>>
>> Does this make any sense to anyone else?
>>
>> 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: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
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
Re: Multi-tree HDK config - working directory ( was Re: Supporting
working on a single module?)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Alexey Petrenko wrote:
> 2006/5/25, Oliver Deakin <ol...@googlemail.com>:
>> I imagine that an HDK would come in a zip format, much like the current
>> snapshots [2].
> I also suggest to add build date into zip name and internal directory name.
> Something like HDK_20060525/deploy and so on...
Yes, I assumed we'd be stamping it that way, but it's good to state it
so it can be discussed.
>
> It will let us keep few copies of HDK in the same place for testing
> purposes.
That is what I've been driving at... it's a combination of either
multiple version for testing a single codebase, one version for multiple
development projects (Aka Mark), or a combination. Add in the variance
w/ VMs...
I think of this like the SDK. I have multiple different versions of the
SDK on my machine (1.4, 5, ...) and when working in a project, I
configure the environment to use the version I need. I don't keep them
in zip files, and unzip the Java SDK into each project....
geir
---------------------------------------------------------------------
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
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
Posted by Alexey Petrenko <al...@gmail.com>.
2006/5/25, Oliver Deakin <ol...@googlemail.com>:
> I imagine that an HDK would come in a zip format, much like the current
> snapshots [2].
I also suggest to add build date into zip name and internal directory name.
Something like HDK_20060525/deploy and so on...
It will let us keep few copies of HDK in the same place for testing purposes.
--
Alexey A. Petrenko
Intel Middleware Products Division
Re: Multi-tree HDK config - working directory ( was Re: Supporting
working on a single module?)
Posted by Oliver Deakin <ol...@googlemail.com>.
Geir Magnusson Jr wrote:
>
>
> Vladimir Gorr wrote:
>
>> whether does it mean the HDK will contain the sources (src.zip?) as
>> well?
>> Otherwise I don't understand what can be modified. Could you please
>> clarify
>> this?
>>
>
> I know you addressed to oliver, but let me take a wack at it to see if
> I grok everything....
>
> One of the many motivations for the HDK idea was a refactoring of the
> natives into modules, which brought up the interdependency issue. To
> solve, the idea is top copy natives headers at build time into One Big
> Pile.
From the work Im currently doing on attempting to move the
native-src/*/include directory
contents into their appropriate modules, using the modularised natives
layout I
described previously [1], the "One Big Pile" actually doesnt look that
bad - for the classlib
there are actually only 13 header files that need to be shared between
modules, and we
might be able to reduce these with extra work.
>
> So if you are in module foo, and working on something that modified
> foo.h, foo.h will be copied at build from module foo into One Big
> Pile, thereby overwriting the HDK's copy of foo.h, since the HDK and
> One Big Pile are conflated in the current model.
foo.h will only be copied into the include area of the HDK if it is
required by other
modules. If it is only used by the natives in that module, it will stay
where it is.
>
> I don't like this, because as I am a forgetful person, I may point
> another project/module at the HDK, and now will be tormented by
> strange things happening because the foo.h has been changed...
>
> That's why I've been suggesting a model (just for everyone's sanity,
> including people posting questions to the dev list), where the HDK is
> never modified, and there's a "working" area in the individual project
> tree where HDK + ThingsBeingWorkedOn are intermingled for the build
> process local to that individual project.
Isnt that just overwriting a copy of the HDK instead of the original?
What is the
original HDK being used for then?
Regards,
Oliver
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c4463654A.3080105@googlemail.com%3e
>
> geir
>
> ---------------------------------------------------------------------
> 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
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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
Re: Multi-tree HDK config - working directory ( was Re: Supporting
working on a single module?)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Vladimir Gorr wrote:
> whether does it mean the HDK will contain the sources (src.zip?) as well?
> Otherwise I don't understand what can be modified. Could you please clarify
> this?
>
I know you addressed to oliver, but let me take a wack at it to see if I
grok everything....
One of the many motivations for the HDK idea was a refactoring of the
natives into modules, which brought up the interdependency issue. To
solve, the idea is top copy natives headers at build time into One Big Pile.
So if you are in module foo, and working on something that modified
foo.h, foo.h will be copied at build from module foo into One Big Pile,
thereby overwriting the HDK's copy of foo.h, since the HDK and One Big
Pile are conflated in the current model.
I don't like this, because as I am a forgetful person, I may point
another project/module at the HDK, and now will be tormented by strange
things happening because the foo.h has been changed...
That's why I've been suggesting a model (just for everyone's sanity,
including people posting questions to the dev list), where the HDK is
never modified, and there's a "working" area in the individual project
tree where HDK + ThingsBeingWorkedOn are intermingled for the build
process local to that individual project.
geir
---------------------------------------------------------------------
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
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
Posted by Vladimir Gorr <vv...@gmail.com>.
On 5/25/06, Oliver Deakin <ol...@googlemail.com> wrote:
>
>
> Vladimir Gorr wrote:
> > On 5/25/06, Oliver Deakin <ol...@googlemail.com> wrote:
> >>
> >> Geir Magnusson Jr wrote:
> >> > Some stuff that got lost (because I got consumed by J1 and I was the
> >> > only one pushing on it) was the idea of ensuring that
> >> >
> >> > 1) the HDK could be anywhere - the was no hard-wired spot. That
> >> > allowed having multiple simultaneous HDKs (ex different snapshot
> >> > version) at the same time as a full build
> >>
> >> Perhaps the HDK would have a default location which could be overridden
> >> by passing a command line option to the build scripts - possibly in a
> >> similar
> >> way to Marks suggestion for selection of the rmi module location [1].
> >> My modifications to build an HDK from the classlib code (HARMONY-469)
> >> use an Ant property hy.hdk to specify the root directory of the HDK.
> >> With
> >> the current patch, this property doesnt quite propagate all the way
> down
> >> to the native makefiles, but this shouldnt be too hard to extend. Once
> >> this
> >> was done, a developer could then override the default HDK location
> using
> >> a command line similar to:
> >>
> >> ant -Dhy.hdk=/my/hdk/location -f make/build.xml
> >>
> >>
> >> The default HDK location would probably depend on what area you are
> >> working
> >> on - in classlib the trunk/deploy directory is the default build
> >> location at the
> >> moment, and I think it makes sense to keep this as the default HDK
> >> directory.
> >>
> >> >
> >> > 2) the build should ensure that the materials of the HDK never get
> >> > overwritten so that we can always tell a contributor w/ a question
> >> > "first, before we debug this, do a ant hdk-copy.." or something to
> >> > easily get them to a known good state.
> >> >
> >> > This to me sounds like we need some kind of working directory and a
> >> > 'hdk-copy' target.
> >> >
> >> > The working model then allows freedom of choosing an hdk or a current
> >> > full build as the 'base' to work with...
> >>
> >> I imagine that an HDK would come in a zip format, much like the current
> >> snapshots [2].
> >> If this was the case, then once you have downloaded the HDK zip, you
> can
> >> unpack it
> >> into your working directory where it will be modified.
> >
> >
> > Oliver,
> >
> > whether does it mean the HDK will contain the sources (src.zip?) as
> well?
> > Otherwise I don't understand what can be modified. Could you please
> > clarify
> > this?
>
> Hi Vladimir,
>
> When you rebuild, the old versions of binaries (dll/so/jar etc.) would
> be overwritten
> with the new versions that are built from your altered code, and
> potentially altered
> header files will be replaced (e.g. jni.h).
Hi Oliver,
if I correctly understand ALL will be re-built in this case but not only the
altered sources.
I mean the following. Suppose, at first, I check out the Harmony sources on
my machine.
The next step is the downloading the HDK pre-compiled from these sources
some time ago.
Note the dates for both binaries & sources files will be up-to-date (I
mean they will differ from original ones)
and therefore the 'ant -Dhy.hdk=/my/hdk/location -f make/build.xml' command
will re-compile all sources
from scratch (due to all dependencies were lost). IMHO the idea of HDK was
different (at least I understood so).
AFAIU it's supposed re-using the pre-compiled binaries for the lazy
developers. Or am I wrong?
Thanks,
Vladimir.
This is similar to the current system, where you can use a snapshot
> build to rebuild
> Java code against, and you can then drop your rebuilt jars over those of
> the snapshot
> to create an updated jre.
>
> The HDK will contain binaries to build against, and some necessary
> header files, but
> no complete src.zip.
> I have put up a proposed description of the HDK on the website [1], which
> summarises some of the ideas in this thread so far. I hope it helps
> clarify :)
>
> Regards,
> Oliver
>
> [1]
> http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html
>
> > Thanks,
> > Vladimir.
> >
> > However, you still have the
> >> original zip to fall back on if you need to. I'm not sure that we need
> >> an extra build
> >> target for this process - to get back to a known good state, you can
> >> just unpack the
> >> zip again into your working directory.
> >>
> >> Am I missing something?
> >>
> >> Regards,
> >> Oliver
> >>
> >> [1]
> >>
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c200605240628.k4O6S6TX002666@d06av02.portsmouth.uk.ibm.com%3e
> >>
> >> [2] http://people.apache.org/dist/incubator/harmony/snapshots/
> >>
> >> >
> >> > Does this make any sense to anyone else?
> >> >
> >> > 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: harmony-dev-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> >> >
> >> >
> >>
> >> --
> >> Oliver Deakin
> >> IBM United Kingdom Limited
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >>
> >>
> >
>
> --
> Oliver Deakin
> IBM United Kingdom Limited
>
>
> ---------------------------------------------------------------------
> 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
>
>
Re: Multi-tree HDK config - working directory ( was Re: Supporting
working on a single module?)
Posted by Oliver Deakin <ol...@googlemail.com>.
Vladimir Gorr wrote:
> On 5/25/06, Oliver Deakin <ol...@googlemail.com> wrote:
>>
>> Geir Magnusson Jr wrote:
>> > Some stuff that got lost (because I got consumed by J1 and I was the
>> > only one pushing on it) was the idea of ensuring that
>> >
>> > 1) the HDK could be anywhere - the was no hard-wired spot. That
>> > allowed having multiple simultaneous HDKs (ex different snapshot
>> > version) at the same time as a full build
>>
>> Perhaps the HDK would have a default location which could be overridden
>> by passing a command line option to the build scripts - possibly in a
>> similar
>> way to Marks suggestion for selection of the rmi module location [1].
>> My modifications to build an HDK from the classlib code (HARMONY-469)
>> use an Ant property hy.hdk to specify the root directory of the HDK.
>> With
>> the current patch, this property doesnt quite propagate all the way down
>> to the native makefiles, but this shouldnt be too hard to extend. Once
>> this
>> was done, a developer could then override the default HDK location using
>> a command line similar to:
>>
>> ant -Dhy.hdk=/my/hdk/location -f make/build.xml
>>
>>
>> The default HDK location would probably depend on what area you are
>> working
>> on - in classlib the trunk/deploy directory is the default build
>> location at the
>> moment, and I think it makes sense to keep this as the default HDK
>> directory.
>>
>> >
>> > 2) the build should ensure that the materials of the HDK never get
>> > overwritten so that we can always tell a contributor w/ a question
>> > "first, before we debug this, do a ant hdk-copy.." or something to
>> > easily get them to a known good state.
>> >
>> > This to me sounds like we need some kind of working directory and a
>> > 'hdk-copy' target.
>> >
>> > The working model then allows freedom of choosing an hdk or a current
>> > full build as the 'base' to work with...
>>
>> I imagine that an HDK would come in a zip format, much like the current
>> snapshots [2].
>> If this was the case, then once you have downloaded the HDK zip, you can
>> unpack it
>> into your working directory where it will be modified.
>
>
> Oliver,
>
> whether does it mean the HDK will contain the sources (src.zip?) as well?
> Otherwise I don't understand what can be modified. Could you please
> clarify
> this?
Hi Vladimir,
When you rebuild, the old versions of binaries (dll/so/jar etc.) would
be overwritten
with the new versions that are built from your altered code, and
potentially altered
header files will be replaced (e.g. jni.h).
This is similar to the current system, where you can use a snapshot
build to rebuild
Java code against, and you can then drop your rebuilt jars over those of
the snapshot
to create an updated jre.
The HDK will contain binaries to build against, and some necessary
header files, but
no complete src.zip.
I have put up a proposed description of the HDK on the website [1], which
summarises some of the ideas in this thread so far. I hope it helps
clarify :)
Regards,
Oliver
[1] http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html
> Thanks,
> Vladimir.
>
> However, you still have the
>> original zip to fall back on if you need to. I'm not sure that we need
>> an extra build
>> target for this process - to get back to a known good state, you can
>> just unpack the
>> zip again into your working directory.
>>
>> Am I missing something?
>>
>> Regards,
>> Oliver
>>
>> [1]
>>
>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c200605240628.k4O6S6TX002666@d06av02.portsmouth.uk.ibm.com%3e
>>
>> [2] http://people.apache.org/dist/incubator/harmony/snapshots/
>>
>> >
>> > Does this make any sense to anyone else?
>> >
>> > 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: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>>
>> --
>> Oliver Deakin
>> IBM United Kingdom Limited
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
Posted by Vladimir Gorr <vv...@gmail.com>.
On 5/25/06, Oliver Deakin <ol...@googlemail.com> wrote:
>
> Geir Magnusson Jr wrote:
> > Some stuff that got lost (because I got consumed by J1 and I was the
> > only one pushing on it) was the idea of ensuring that
> >
> > 1) the HDK could be anywhere - the was no hard-wired spot. That
> > allowed having multiple simultaneous HDKs (ex different snapshot
> > version) at the same time as a full build
>
> Perhaps the HDK would have a default location which could be overridden
> by passing a command line option to the build scripts - possibly in a
> similar
> way to Marks suggestion for selection of the rmi module location [1].
> My modifications to build an HDK from the classlib code (HARMONY-469)
> use an Ant property hy.hdk to specify the root directory of the HDK. With
> the current patch, this property doesnt quite propagate all the way down
> to the native makefiles, but this shouldnt be too hard to extend. Once
> this
> was done, a developer could then override the default HDK location using
> a command line similar to:
>
> ant -Dhy.hdk=/my/hdk/location -f make/build.xml
>
>
> The default HDK location would probably depend on what area you are
> working
> on - in classlib the trunk/deploy directory is the default build
> location at the
> moment, and I think it makes sense to keep this as the default HDK
> directory.
>
> >
> > 2) the build should ensure that the materials of the HDK never get
> > overwritten so that we can always tell a contributor w/ a question
> > "first, before we debug this, do a ant hdk-copy.." or something to
> > easily get them to a known good state.
> >
> > This to me sounds like we need some kind of working directory and a
> > 'hdk-copy' target.
> >
> > The working model then allows freedom of choosing an hdk or a current
> > full build as the 'base' to work with...
>
> I imagine that an HDK would come in a zip format, much like the current
> snapshots [2].
> If this was the case, then once you have downloaded the HDK zip, you can
> unpack it
> into your working directory where it will be modified.
Oliver,
whether does it mean the HDK will contain the sources (src.zip?) as well?
Otherwise I don't understand what can be modified. Could you please clarify
this?
Thanks,
Vladimir.
However, you still have the
> original zip to fall back on if you need to. I'm not sure that we need
> an extra build
> target for this process - to get back to a known good state, you can
> just unpack the
> zip again into your working directory.
>
> Am I missing something?
>
> Regards,
> Oliver
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c200605240628.k4O6S6TX002666@d06av02.portsmouth.uk.ibm.com%3e
> [2] http://people.apache.org/dist/incubator/harmony/snapshots/
>
> >
> > Does this make any sense to anyone else?
> >
> > 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> --
> Oliver Deakin
> IBM United Kingdom Limited
>
>
> ---------------------------------------------------------------------
> 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
>
>
Re: Multi-tree HDK config - working directory ( was Re: Supporting
working on a single module?)
Posted by Oliver Deakin <ol...@googlemail.com>.
Geir Magnusson Jr wrote:
> Some stuff that got lost (because I got consumed by J1 and I was the
> only one pushing on it) was the idea of ensuring that
>
> 1) the HDK could be anywhere - the was no hard-wired spot. That
> allowed having multiple simultaneous HDKs (ex different snapshot
> version) at the same time as a full build
Perhaps the HDK would have a default location which could be overridden
by passing a command line option to the build scripts - possibly in a
similar
way to Marks suggestion for selection of the rmi module location [1].
My modifications to build an HDK from the classlib code (HARMONY-469)
use an Ant property hy.hdk to specify the root directory of the HDK. With
the current patch, this property doesnt quite propagate all the way down
to the native makefiles, but this shouldnt be too hard to extend. Once this
was done, a developer could then override the default HDK location using
a command line similar to:
ant -Dhy.hdk=/my/hdk/location -f make/build.xml
The default HDK location would probably depend on what area you are working
on - in classlib the trunk/deploy directory is the default build
location at the
moment, and I think it makes sense to keep this as the default HDK
directory.
>
> 2) the build should ensure that the materials of the HDK never get
> overwritten so that we can always tell a contributor w/ a question
> "first, before we debug this, do a ant hdk-copy.." or something to
> easily get them to a known good state.
>
> This to me sounds like we need some kind of working directory and a
> 'hdk-copy' target.
>
> The working model then allows freedom of choosing an hdk or a current
> full build as the 'base' to work with...
I imagine that an HDK would come in a zip format, much like the current
snapshots [2].
If this was the case, then once you have downloaded the HDK zip, you can
unpack it
into your working directory where it will be modified. However, you
still have the
original zip to fall back on if you need to. I'm not sure that we need
an extra build
target for this process - to get back to a known good state, you can
just unpack the
zip again into your working directory.
Am I missing something?
Regards,
Oliver
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c200605240628.k4O6S6TX002666@d06av02.portsmouth.uk.ibm.com%3e
[2] http://people.apache.org/dist/incubator/harmony/snapshots/
>
> Does this make any sense to anyone else?
>
> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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