Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of denis.sharypov@gmail.com
 designates 64.233.184.235 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=izFy+l7LIDKFyAraK6EGILsGl3uKMOocNdq74bGyFFI1vie5ep62kh/XKqgb22M3M6VWr4O27ZYMy+aQAsw5X3n65ue6BnfelIOWjlECitVKybXRX2Arlszer5ivI/JtnkDIlnCRzQ0QZkWr5cNsOSPwGRUBPPDju4RkiEmN7qE=
Message-ID: <b0517cc0606090302v3308bd9cwb46b2790e2f56ea9@mail.gmail.com>
Date: Fri, 9 Jun 2006 14:02:57 +0400
From: "Denis Sharypov" <denis.sharypov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] build -unhook the classlib build and point to the
 existing in-tree one
In-Reply-To: <448847BF.6030900@pobox.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_14528_17312941.1149847377782"
References: <b0517cc0606080710g44663499i47e7d2d03ea03fc0@mail.gmail.com>
	 <4488364D.8020001@pobox.com> <44883CFD.8020009@pobox.com>
	 <23951bd90606080842w41aa036bla8f8aa0d0847ca42@mail.gmail.com>
	 <448847BF.6030900@pobox.com>

------=_Part_14528_17312941.1149847377782
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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.

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


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.

 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.

-- 
Denis Sharypov,
Intel Middleware Products Division

On 6/8/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>
> 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 <geir@pobox.com> 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: 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
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> 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
>
>


-- 
Denis Sharypov,
Intel Middleware Products Division

------=_Part_14528_17312941.1149847377782--