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 ashishwave@gmail.com designates
 64.233.162.203 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=V3BMKRXnbHX6wG4qgHY+ThHCVN4PLygjNVdfqjqtJhfAwkjiDmhBW1X4VbuRnAMlKY69PjqnTw1CLl7idR6Y1+edW2+hT5XeKc3ChBgF0ZYwBNeOdIXz8/ZwJA/Al0dFDd+B7c9S0bcwYZ/8F1c97Y3pwb0g+jPMsP+Aqv9CeiY=
Message-ID: <4f8781f20511230703p146defe7kd5eb9be2a6c8d635@mail.gmail.com>
Date: Wed, 23 Nov 2005 20:33:09 +0530
From: Ashish Ranjan <ashishwave@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: Building choices (was: Re: Code contribution to harmony)
In-Reply-To: 
 <OFA75F1712.0393A504-ON852570C2.00503D07-852570C2.00519080@ca.ibm.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_5467_12615693.1132758189495"
References: <4381BACC.5090305@gmail.com>
	 <OFA75F1712.0393A504-ON852570C2.00503D07-852570C2.00519080@ca.ibm.com>

------=_Part_5467_12615693.1132758189495
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

that is the most convincing argument till now.   :-)
bye :-)
Ashish Ranjan
India
ashishwave@yahoo.com

On 11/23/05, Graeme Johnson <Graeme_Johnson@ca.ibm.com> wrote:
>
> Tim Ellison <t.p.ellison@gmail.com> wrote on 11/21/2005 07:17:16 AM:
>
> > Andrey Chernyshev wrote:
> > > On 11/15/05, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > >
> > >>In the end we decided to go with a 'conventional' native code tool se=
t
> > >>for the native source, and 'conventional' Java code tools for the Jav=
a
> > >>source.  People just felt more comfortable with that.
> > >>
> > >>Do you think we are missing out on something ;-) ?
> > >
> > >
> > > Well, I can see a few potential issues with such "mixed" approach:
> > > - In order to contribute, people would have to learn both building
> > > technologies - Ant and make, someone may give up.
> >
> > I don't see a great advantage to asking people to learn 'cpptask' rathe=
r
> > than 'make'.  I would suggest that many more C programmers are familiar
> > with 'make' already, so we are not asking them to learn something new.
> >
> > [snip]
>
> 'make' also simplifies the bootstrapping issue.  When you are doing the
> initial port of the VM to a new platform, and you don't have java
> running yet, having your build instructions encoded in Ant is problematic=
.
>
> Relying on the availability of a previous java port to get the Harmony
> VM building seems like a questionable porting story.  'make' of one flavo=
r
>
> or another is pretty much universally available, and seems like the
> pragmatic choice for building C code.
>
> Graeme Johnson
> J9 VM Team, IBM Canada.
>

------=_Part_5467_12615693.1132758189495--