You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Peter Karman <pe...@peknet.com> on 2010/01/06 03:21:25 UTC
Re: [Lucy] Monolithic Charmonizer files
Marvin Humphrey wrote on 1/5/10 4:47 PM:
> At its present size, we should just consolidate and work on the consolidated
> files directly. Compiling as a monolithic file is plenty fast.
Where's the win in consolidating into a single .c file? I.e., why would I want
to build Charmonizer as a standalone entity?
Or put another way, how does this help us get to Lucy 1.0?
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [Lucy] Monolithic Charmonizer files
Posted by Nathan Kurz <na...@verse.com>.
On Tue, Jan 5, 2010 at 7:21 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>> 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.
Actually, I was (and am) just generally having computer problems. My
laptop hard drive has been dying a prolonged death, the desktop has
random lock ups when I install all the RAM, etc. I didn't actually
have problems compiling per-se, but I didn't feel I could test what
I'd done well enough to check it in. A simple 'make test' option was
what felt most lacking.
I'm pro-Makefile, and would be happy to write a simple one that should
work fine with GCC. I'm not against a single file solution, though.
For a simple configuration system that's designed to be integrated
into other build systems, it might be a good choice.
In addition to SQLite, dlmalloc might be a good single-file
role-model: <http://g.oswego.edu/dl/html/malloc.html>. Still might
be worth having a tiny Makefile even for the single file solution,
though.
Nathan Kurz
nate@verse.com
Re: [Lucy] Monolithic Charmonizer files
Posted by Marvin Humphrey <ma...@rectangular.com>.
> > I.e., why would I want to build Charmonizer as a standalone entity?
PS: My thought process went something like this... how do I give Nate a
Makefile? That's gonna be too much work... Hey wait, if we consolidate
everyting into one C file, we don't really need a Makefile any more.
Marvin Humphrey
Re: [Lucy] Monolithic Charmonizer files
Posted by Peter Karman <pe...@peknet.com>.
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
Re: [Lucy] Monolithic Charmonizer files
Posted by Marvin Humphrey <ma...@rectangular.com>.
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.
Marvin Humphrey