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...
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
