incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] building withOUT perl
Date Fri, 01 Jul 2011 20:52:59 GMT
On Fri, Jul 01, 2011 at 11:05:44AM +0200, Torsten Curdt wrote:
> would love to give Lucy a whirl ...but the build system ...hmm.

For background...  The code base that is now Lucy began life as a pure Perl
distribution.  It has evolved towards C over time, but it still retains its
Perl heritage.  Perhaps that helps to explain why the build system is the way
it is.

That said, we are continuing the process of migrating away from Perl.  The
transition is largely complete for one of Lucy's layers[1] -- Joe Schaefer got
a solid chunk working with Make just before the podling
swallowed him whole.

> I would be interested in testing Lucy from Objective-C.


> Let's say it would be great to have "normal" build system that
> builds a lib and then have Perl stuff on top of that.
> Would that be something of common interest?

Peter Karman answered a nearly identical question a few weeks ago:

    Lucy isn't designed as a linkable library, though that's a common
    misunderstanding (I had that misunderstanding at first too). The
    traditional model is a standalone C library, compiled independently, and
    then a dynamic language like Ruby, using something like SWIG or FFI, gets
    linked to the C library and accesses the C library functions through the
    dynamic host language bindings.

    Instead of that traditional model, Lucy provides a nearly-complete C
    implementation, like a kit. Each dynamic host language then needs to write
    some required functions in a binding module using Clownfish, and then the
    whole thing is compiled once into a language-specific binary. There is no
    independent, linkable C library. That's actually a feature.

    The Lucy model arose out of a desire on the part of the KinoSearch (Perl)
    and Ferret (Ruby) projects to share C code between them, while retaining
    the highly idiomatic and language-specific optimizations of the respective
    projects. They could have done the traditional linkable C library
    approach. IMO the Clownfish approach offers some nice advantages, not
    least the ability to override C classes in the native host language. 

These days, the majority of our development energies are going towards
expanding Lucy's availability (as opposed to say, improving search-related
features).  The first step was getting all the licensing issues resolved and
getting our inaugural release out.  Now there are two prongs: addressing OS
portability issues and adding bindings to new host languages, such as Ruby,
Python, TCL, and Objective C.

We're not quite at a place where adding a new binding is a turnkey process.
Once our next release is done, I'm going to go back to working on
<>, "Port Clownfish compiler to
C".  We're whittling down the barriers, inch by inch.

If you want to wait until it's more straightforward to bind Lucy to Objective
C, feel free to lurk as some of our Ruby and TCL volunteers are doing right
now.  If you'd like to help us move along that path more quickly, as Joe
Shaefer has, we'll be happy to match you up with the tasks you'd find most
interesting to work on.


Marvin Humphrey

[1] Lucy's "Charmonizer" layer now uses Makefiles.  For a primer on Lucy's
    layers, see Lucy::Docs::DevGuide:

View raw message