Re: [drlvm] build -unhook the classlib build and point to the existing in-tree one
Thanks for this. I'm figuring it out. It's pretty logical once you
start to figure it out in that you can start to guess where things might
be. There seem to be multiple places that would be valid w/
parent-child relationships, but that's no different than make. I don't
like what I'm guessing are constructed properties, like the includes
property in the extra.apr project appears as 'extra.apr.includes
later, which makes searching for where props are originally set somewhat
of a easter-egg hunt...
more inline...
Denis Sharypov wrote:
I would like to give the background on how the build system is designed and
then
give answers for the specific questions.
The build system provided with the VM is designed to be able to build the
whole harmony codebase
no matter how many modules it contains. The intent was to propose it later
as a unified build system
for the Harmony project after receiving the community feedback.
Speaking for myself, I'd personally prefer a much more loosely coupled
build framework, to allow the individual parts of Harmony (drlvm,
jchevm, classlib, tools, etc) the freedom to build in the way best
suited for that part, as determined by the people working on that part.
There has to be some overall federation, such as where generated
artifacts are to be placed when generating a JDK, but I'm hoping that
coupling doesn't have to be tight.
Others agree, disagree?
The main notion the build operates with is a component - a more or less
distinct part of product (vm, classlib, tools, etc).
The benefits are:
- A component can contain several types of source:
C++ sources, C sources, assembler sources, Java* sources, smoke
and unit tests.
- A component can be processed in several ways in the build:
produce native output (shared or static library or executable)
and/or Java* classes in .jar file, produce and run smoke and/or unit
tests.
- One can switch between the different compilers and modes by using
the environment variables, as follows:
On Windows*: | On
Linux*:
-+
MSVC compiler : set CXX=msvc | N/A
Intel(R) compiler : set CXX=icl| export
CXX=icc
GCC compiler : N/A | export
CXX=gcc
Release : set BUILD_CFG=release | export
BUILD_CFG=release
Debug: set BUILD_CFG=debug | export
BUILD_CFG=debug
The build dynamically produces a build_${component}.xml file for
each specific component by taking its descriptor, performing the
attribute-based filtering on it, and then applying target templates
and settings on it.
The README describing how to write a component descriptor can be found at:
harmony/enhanced/drlvm/trunk/README.txt
Now, as a build system for the drlvm (alone), I do think it's a pretty
interesting system - very slick - but I do wonder about the ease at
which we can adapt it to new things as they come along, and how easy new
people can grok it and help out. That last factor is critical.
Here are the answers on questions:
Component-oriented build system is designed to support project layout this
way :
/drlvm/
/classlib/
/tools/
/deploy/
The external resources such as APR, ECLIPSE, CPPTASKS, ZLIB, etc are
described in enhanced/drlvm/trunk/build/make/win.properties and
enhanced/drlvm/trunk/build/make/linux.properties for each system
respectively.
yep - that I know
Each network resource location is configured as follows:
remote.resource name.archive=Resource URL or local path to zip
archive
Which can be overridden through the system environment as follows:
resource name_HOME=extracted archive location
For example, the build takes Eclipse from it's default location on Windows:
remote.ECLIPSE.archive=http://mirrors.cat.pdx.edu/eclipse/eclipse/downloads/drops/R-3.1.1-200509290840/eclipse-JDT-3.1.1.zip
unless the ECLIPSE_HOME is set and points to the Eclipse installation
directory.
The build update command downloads resources only once. It may be
overridden by setting resource name_HOME=extracted archive location
variables.
The build is invokable from above by calling build.bat or build.sh
depending
on the operating system.
It is possible to specify only certain compnent(s) to build:
build.bat -DCOMPONENTS=vm extra classlib
However, currently vm component is rigidly dependent on classlib and will
initiate classlib building. I can't provide the patch to unhook vm and
class
libs today, but please allow a bit more time, and the patch will appear.
Ok - but if we can turn this into a conversation/tutorial here on the
list, that would be better than a patch thrown over the wall. It will
help people learn more about this system...
Re: [drlvm] build -unhook the classlib build and point to the existing in-tree one
Currently two VM subcomponents - vmi and kernel_classes - explicitly depend on classlibs. It's needed to get rid of this and then bootstrap prebuilt harmony classlib while building vm subcomponents. Here're the extracts from the correponding xml descriptors describing dependency: project name=vm.vmi target name=init depends=common_vm property name=build.depends value=classlib.vmi_includes, extra.apr, vm.vmcore, classlib.pool, classlib.zip, classlib.port / project name=vm.kernel_classes target name=init depends=common_vm property name=build.java.depends value=classlib.luni,classlib.security,classlib.archive, classlib.regex,classlib.nio,classlib.nio_char/ -- Denis Sharypov, Intel Middleware Products Division It is possible to specify only certain compnent(s) to build: build.bat -DCOMPONENTS=vm extra classlib However, currently vm component is rigidly dependent on classlib and will initiate classlib building. I can't provide the patch to unhook vm and class libs today, but please allow a bit more time, and the patch will appear. Ok - but if we can turn this into a conversation/tutorial here on the list, that would be better than a patch thrown over the wall. It will help people learn more about this system... 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: [drlvm] build -unhook the classlib build and point to the existing in-tree one
Geir Magnusson Jr wrote: snip Denis Sharypov wrote: I would like to give the background on how the build system is designed and then give answers for the specific questions. The build system provided with the VM is designed to be able to build the whole harmony codebase no matter how many modules it contains. The intent was to propose it later as a unified build system for the Harmony project after receiving the community feedback. Speaking for myself, I'd personally prefer a much more loosely coupled build framework, to allow the individual parts of Harmony (drlvm, jchevm, classlib, tools, etc) the freedom to build in the way best suited for that part, as determined by the people working on that part. There has to be some overall federation, such as where generated artifacts are to be placed when generating a JDK, but I'm hoping that coupling doesn't have to be tight. Others agree, disagree? Agreed - IMHO using a build system for each VM or classlib that most suits that particular component makes sense. Classlib currently has a fairly straightforward build system (which could probably be simplified further with some work), and this is good enough for it - it suits all the requirements of that component and is easy to use. DRLVM has a more complex build system, but probably with some justification due to the complexity of the project it is compiling. As long as they produce binaries that can be combined (adhere to the VMI, produced JDK 'shape' is standard etc.) then I dont think it matters if the underlying build systems are the same. Regards, Oliver -- 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: [drlvm] build -unhook the classlib build and point to the existing in-tree one
To stop using the auto-download classlib and harmony JIRA fetches, and point the build at the existing classlib that's stored locally you should do the following: edit harmony/enhanced/drlvm/trunk/build/make/win.properties or harmony/enhanced/drlvm/trunk/build/make/linux.properties file: comment out remote.CLASSLIB.archive=-r 385366 https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk remote.CLASSLIB.archive.type=svn and add CLASSLIB_HOME=relative path to classlib -- Denis Sharypov, Intel Middleware Products Division
Re: [drlvm] build -unhook the classlib build and point to the existing in-tree one
Ok - perfect - and this assumes the standard location for jars/dlls? Denis Sharypov wrote: To stop using the auto-download classlib and harmony JIRA fetches, and point the build at the existing classlib that's stored locally you should do the following: edit harmony/enhanced/drlvm/trunk/build/make/win.properties or harmony/enhanced/drlvm/trunk/build/make/linux.properties file: comment out remote.CLASSLIB.archive=-r 385366 https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk remote.CLASSLIB.archive.type=svn and add CLASSLIB_HOME=relative path to classlib - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] build -unhook the classlib build and point to the existing in-tree one
Maybe I wasn't clear. I dont' want DRLVM to then try and build that classlib, I just want it to use it, as is... geir Geir Magnusson Jr wrote: Ok - perfect - and this assumes the standard location for jars/dlls? Denis Sharypov wrote: To stop using the auto-download classlib and harmony JIRA fetches, and point the build at the existing classlib that's stored locally you should do the following: edit harmony/enhanced/drlvm/trunk/build/make/win.properties or harmony/enhanced/drlvm/trunk/build/make/linux.properties file: comment out remote.CLASSLIB.archive=-r 385366 https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk remote.CLASSLIB.archive.type=svn and add CLASSLIB_HOME=relative path to classlib - 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: [drlvm] build -unhook the classlib build and point to the existing in-tree one
Geir, unfortunately the DRLVM build system doesn't allow to make you wish. Obviously it should be modified to build the recent version of class library from SVN using the original build system. Whether do I correctly understand you are interested to have only one build system for class library? And your preference is not the DRLVM one, right? Thanks, Vladimir. On 6/8/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Maybe I wasn't clear. I dont' want DRLVM to then try and build that classlib, I just want it to use it, as is... geir Geir Magnusson Jr wrote: Ok - perfect - and this assumes the standard location for jars/dlls? Denis Sharypov wrote: To stop using the auto-download classlib and harmony JIRA fetches, and point the build at the existing classlib that's stored locally you should do the following: edit harmony/enhanced/drlvm/trunk/build/make/win.properties or harmony/enhanced/drlvm/trunk/build/make/linux.properties file: comment out remote.CLASSLIB.archive=-r 385366 https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk remote.CLASSLIB.archive.type=svn and add CLASSLIB_HOME=relative path to classlib - 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: [drlvm] build -unhook the classlib build and point to the existing in-tree one
oh. Well, I'll try that - it's a step forward. I do think we need to rapidly come to a conclusion on what to do. I think we want to have the drlvm build : 1) point anywhere to a hdk/classlib that's prebuilt and just use the artifacts in it 2) be invokable from 'above' (as described below) 3) change how the dependencies work. I think it's nice to be able to do what it does, but we also need to have the ability to keep those around locally indep of drlvm, and just use properties to tell drlvm where to find those resources too, so that way if I have a regular distribution of say APR on my machine, I can just use it. Now, this is something for all of us to decide, but I imagined our project this way : /drlvm/ /classlib/ /tools/ /deploy/ with each 'subcomponent' (i.e. classlib, drlvm, jchevm) determining it's own build and just having a clear way to be invoked form above. We can then invoke the classlib build and have it deposit it's artifacts into the deploy directory, and then point drlvm to that and have it build from there - and NOT build classlib. Further, building on the HDK stuff, I think we'd also want to be able to do something like : /drlvm/ /hdk/ hdk1/ hdk2/ and point drlvm to build against one of the hdks I really appreciate how easy the existing build makes evaluation of drlvm, but we should consider if we can reuse to get us towards the above, or if we have to re-do in a manner more like classlib, jchevm, etc... geir Vladimir Gorr wrote: Geir, unfortunately the DRLVM build system doesn't allow to make you wish. Obviously it should be modified to build the recent version of class library from SVN using the original build system. Whether do I correctly understand you are interested to have only one build system for class library? And your preference is not the DRLVM one, right? Thanks, Vladimir. On 6/8/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Maybe I wasn't clear. I dont' want DRLVM to then try and build that classlib, I just want it to use it, as is... geir Geir Magnusson Jr wrote: Ok - perfect - and this assumes the standard location for jars/dlls? Denis Sharypov wrote: To stop using the auto-download classlib and harmony JIRA fetches, and point the build at the existing classlib that's stored locally you should do the following: edit harmony/enhanced/drlvm/trunk/build/make/win.properties or harmony/enhanced/drlvm/trunk/build/make/linux.properties file: comment out remote.CLASSLIB.archive=-r 385366 https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk remote.CLASSLIB.archive.type=svn and add CLASSLIB_HOME=relative path to classlib - 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]
Re: [drlvm] build -unhook the classlib build and point to the existing in-tree one
On 8 June 2006 at 22:42, Vladimir Gorr [EMAIL PROTECTED] wrote: Geir, unfortunately the DRLVM build system doesn't allow to make you wish. Obviously it should be modified to build the recent version of class library from SVN using the original build system. Whether do I correctly understand you are interested to have only one build system for class library? And your preference is not the DRLVM one, right? The key point for me is that they should be built separately - i.e. loose coupling. Irrespective of any build system choice(s). -Mark. On 6/8/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Maybe I wasn't clear. I dont' want DRLVM to then try and build that classlib, I just want it to use it, as is... geir Geir Magnusson Jr wrote: Ok - perfect - and this assumes the standard location for jars/dlls? Denis Sharypov wrote: To stop using the auto-download classlib and harmony JIRA fetches, and point the build at the existing classlib that's stored locally you should do the following: edit harmony/enhanced/drlvm/trunk/build/make/win.properties or harmony/enhanced/drlvm/trunk/build/make/linux.properties file: comment out remote.CLASSLIB.archive=-r 385366 https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk remote.CLASSLIB.archive.type=svn and add CLASSLIB_HOME=relative path to classlib - 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] --=_Part_21026_20710290.1149781378142-- - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] build -unhook the classlib build and point to the existing in-tree one
Can I get some help from someone w/ the build? First thing, I want to stop using the auto-download classlib and harmony JIRA fetches, and just point the build at the existing classlib that's in the svn tree. IOW, I have w/ /harmony/enhanced/ as my root : drlvm/trunk/ classlib/trunk/ and I want to change the drlvm to use the stuff in classlib/trunk to build. Maybe if I see the fast way to do that, I'll then be able to start having a /deploy directory peer to drlvm and classlib and can go from there. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
