Mailing-List: contact lucy-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4B4406CA.8060804@peknet.com>
Date: Tue, 05 Jan 2010 21:43:06 -0600
From: Peter Karman <peter@peknet.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: lucy-dev@lucene.apache.org
Subject: Re: [Lucy] Monolithic Charmonizer files
References: <20100105224719.GA15135@rectangular.com>
 <4B43F3A5.1050402@peknet.com> <20100106032102.GA19664@rectangular.com>
In-Reply-To: <20100106032102.GA19664@rectangular.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Marvin Humphrey wrote on 1/5/10 9:21 PM:
> On Tue, Jan 05, 2010 at 08:21:25PM -0600, Peter Karman wrote:
> 
>> Where's the win in consolidating into a single .c file? 
> 
>   * Building Charmonizer becomes as straightforward as compiling
>     "hello_world.c".
>   * We don't have to maintain multiple Makefiles to get Charmonizer to build
>     successfully on different platforms.
>   * I think Charmonizer would work well structured as a single file, because
>     it's a relatively straightforward procedural library -- as opposed to a
>     large OO project which needs strong modularization.
> 
>> I.e., why would I want to build Charmonizer as a standalone entity?
> 
> Right now, just for the sake of hacking on Charmonizer in isolation.  It's a
> little weird that in order to build Charmonizer, you need the build script for
> Lucy's Perl bindings -- that threw off Nate.
> 
>> Or put another way, how does this help us get to Lucy 1.0?
> 
> I've been trying to use feedback supplied by you and Nate to make Charmonizer
> as easy to grok as possible.  We get to 1.0 faster because making Charmonizer
> in particular and Lucy in general as simple as possible makes it easier for
> you and Nate to contribute now, and easier for others to contribute in the
> future.
> 

ok, I buy the "it makes the build architecture simpler, lessening the barrier to 
entry and increasing the immediate-hacking-gratification-factor" argument.


-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com