Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
On 5/25/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: Vladimir Gorr wrote: > On 5/25/06, Oliver Deakin <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED] >> >> [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 ca
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
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/[EMAIL PROTECTED] geir - 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]
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
Vladimir Gorr wrote: On 5/25/06, Oliver Deakin <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED] [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: [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] -- 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]
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
Alexey Petrenko wrote: 2006/5/25, Oliver Deakin <[EMAIL PROTECTED]>: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
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/[EMAIL PROTECTED] [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: [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]
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
On 5/25/06, Oliver Deakin <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED] [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: [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]
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
2006/5/25, Oliver Deakin <[EMAIL PROTECTED]>: 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?)
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/[EMAIL PROTECTED] [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: [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]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
