From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29789 invoked from network); 17 Jul 2008 09:54:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 17 Jul 2008 09:54:15 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 44812 invoked from network); 17 Jul 2008 09:54:11 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Jul 2008 09:54:11 -0000 Received: (qmail 26721 invoked by alias); 17 Jul 2008 09:54:08 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25293 Received: (qmail 26700 invoked from network); 17 Jul 2008 09:54:08 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 17 Jul 2008 09:54:08 -0000 Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by bifrost.dotsrc.org (Postfix) with ESMTP id F0BEC80561C2 for ; Thu, 17 Jul 2008 11:54:04 +0200 (CEST) Received: by wr-out-0506.google.com with SMTP id 50so4361412wra.13 for ; Thu, 17 Jul 2008 02:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=q3rwRU4mbOL70yiu81S+g07j+A8jQjIrxtUYV03AQac=; b=rwuTS+5nDq0KKDv+UdZdK3r7p3YPJWHB8XO9MhukznbmSUqMZzr2jy2Ll6rOMe3uTb 6zNRJ0DcXyzSspyklDCDgzG/f2w7NZT4joE+LUtbHl2QzYZ1pKWpU85E9i4vTBEn9XKs 4obqzoaQzh9zEiXp3wnSRsu2ta8OEzRTbbpqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=O2+a+7ZacxW6M+pdezFCIYsY8qCc4pwRBUQncspA6R56B/SEaCbyGw1CGQQa0qoOJE /u1sO1Qcsd0Ui81G+Q2q/U/mFFFvRr4naLBfrx0LJ2vrezo4Fdw4D2asK/l7CERbD+cH rVjoL3C9sYmz/TscJcw3HDNy+AtWusA1I6BF0= Received: by 10.90.33.5 with SMTP id g5mr3139841agg.33.1216288443875; Thu, 17 Jul 2008 02:54:03 -0700 (PDT) Received: by 10.90.78.14 with HTTP; Thu, 17 Jul 2008 02:54:03 -0700 (PDT) Message-ID: Date: Thu, 17 Jul 2008 15:24:03 +0530 From: "Karthik B" To: "Peter Stephenson" Subject: Re: Zsh migrated to Symbian OS - Contributing back details. Cc: zsh-workers@sunsite.dk, Karthikeyan.Balu@symbian.com In-Reply-To: <20080717101218.144144ac@news01> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_34170_15673527.1216288443868" References: <20080429111157.67641fc2@news01> <20080717101218.144144ac@news01> X-Virus-Scanned: ClamAV 0.92.1/7733/Thu Jul 17 04:32:16 2008 on bifrost X-Virus-Status: Clean ------=_Part_34170_15673527.1216288443868 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline >Ideally, it would be good (both for you to maintain it and >for us not to mess it up) if this could live in a subdirectory, This is really a good option, having a subdirectory for duplicate files to which our make files can point to, but any common changes must be integrated carefully. >the major limitation is that we'll have to be careful that the distribution >doesn't come with files that normally get autogenerated. (I'm not familiar >with Symbian myself.) We will be cautious in not getting the auto generated files distributed... After integration, we must make sure that the existing behaviors on Linux is not broken, so is there any test suite (sort of) to confirm this.? Karthik. On Thu, Jul 17, 2008 at 2:42 PM, Peter Stephenson wrote: > On Thu, 17 Jul 2008 10:47:25 +0530 > "Karthik B" wrote: > > Please reply with your suggestions for contribution. > > > > Here are my views, > > > > 1. Contributing back to the current development brach of the Zsh project. > > - This is just by getting our changes under a compiler switch > specific > > to Symbian, may be __SYMBIAN32__, then making sure the code compiles and > > works as expected for both the platforms. Symbian code structure is > > different from the Zsh project, hence we need to change this to align > with > > Zsh project. > > - Any update to the Symbian specific source can only be performed by > > using the available Symbian SDK for Windows as we currently don't have > one > > for Linux and there is no solution yet to emulate Symbian OS on Linux. > > That's fine... I'm expecting that there'll be #ifdef's in the code; > probably the messier part is working out where to put your non-standard > build code. Ideally, it would be good (both for you to maintain it and > for us not to mess it up) if this could live in a subdirectory, but > Makefile-style files in the source directories aren't a problem. I think > the major limitation is that we'll have to be careful that the distribution > doesn't come with files that normally get autogenerated. (I'm not familiar > with Symbian myself.) > > > 2. Contribution categorised by platform, having a separate code base for > > Symbian. > > - This is just by pushing our code with the current code structure, > the > > integration to this branch would be an extra effort. > > Don't really like this one, I think that's likely to be too much effort to > keep going. I would hope that enough little tweaks could be made by the > Symbian developers to keep the normal code aligned. The fundamentals of > zsh (OS-related parts) don't tend to change that much. > > > 3. Zsh project advertising the source hosted in Symbian Developer > Network. > > - This doesn't need any contribution to the Zsh project, the > integration > > activities will have to be maintained by Symbian. > > This is certainly no problem, but it would be worth at least exploring a > better integration. > > -- > Peter Stephenson Software Engineer > CSR PLC, Churchill House, Cambridge Business Park, Cowley Road > Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 > ------=_Part_34170_15673527.1216288443868 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
>Ideally, it would be good (both for you to maintain it and
>for us not to mess it up) if this could live in a subdirectory,

This is really a good option, having a subdirectory for duplicate files to which our make files
can point to, but any common changes must be integrated carefully.

>the major limitation is that we'll have to be careful that the distribution
>doesn't come with files that normally get autogenerated.  (I'm not familiar
>with Symbian myself.)

We will be cautious in not getting the auto generated files distributed...

After integration, we must make sure that the existing behaviors on Linux is not broken, so is there any test suite (sort of) to confirm this.?

Karthik.


On Thu, Jul 17, 2008 at 2:42 PM, Peter Stephenson <pws@csr.com> wrote:
On Thu, 17 Jul 2008 10:47:25 +0530
"Karthik B" <karthikeyan.balu@gmail.com> wrote:
> Please reply with your suggestions for contribution.
>
> Here are my views,
>
> 1. Contributing back to the current development brach of the Zsh project.
>     - This is just by getting our changes under a compiler switch specific
> to Symbian, may be __SYMBIAN32__, then making sure the code compiles and
> works as expected for both the platforms. Symbian code structure is
> different from the Zsh project, hence we need to change this to align with
> Zsh project.
>     -  Any update to the Symbian specific source can only be performed by
> using the available Symbian SDK for Windows as we currently don't have one
> for Linux and there is no solution yet to emulate Symbian OS on Linux.

That's fine...  I'm expecting that there'll be #ifdef's in the code;
probably the messier part is working out where to put your non-standard
build code.  Ideally, it would be good (both for you to maintain it and
for us not to mess it up) if this could live in a subdirectory, but
Makefile-style files in the source directories aren't a problem.  I think
the major limitation is that we'll have to be careful that the distribution
doesn't come with files that normally get autogenerated.  (I'm not familiar
with Symbian myself.)

> 2. Contribution categorised by platform, having a separate code base for
> Symbian.
>    - This is just by pushing our code with the current code structure, the
> integration to this branch would be an extra effort.

Don't really like this one, I think that's likely to be too much effort to
keep going.  I would hope that enough little tweaks could be made by the
Symbian developers to keep the normal code aligned.  The fundamentals of
zsh (OS-related parts) don't tend to change that much.

> 3. Zsh project advertising the source hosted in Symbian Developer Network.
>     - This doesn't need any contribution to the Zsh project, the integration
> activities will have to be maintained by Symbian.

This is certainly no problem, but it would be worth at least exploring a
better integration.

--
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

------=_Part_34170_15673527.1216288443868--