lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] New branch LUCY-215-cf-extensions
Date Fri, 23 Mar 2012 01:49:42 GMT
On Thu, Mar 22, 2012 at 12:10 PM, Nick Wellnhofer <wellnhofer@aevum.de> wrote:
> I created a new branch LUCY-215-cf-extensions to work on support for C-based
> extensions. As a first step, I made Clownfish handle multiple source
> directories. I added a source_dir member variable to CFCFile, and made some
> changes to the CFCHierarchy API.

I didn't get the chance to review this series of commits thoroughly today, but
I wanted to respond sooner rather than later so expect a followup email from
me about those.

> The next step would be to add member variables for the include dirs to
> CFCHierarchy and parse the .cfh files from the these directories.

Yes.

> Then we'll need a way to determine whether a CFCClass comes from an include
> dir, so we can treat them differently when generating the C headers and the
> boot and parcel code.

Exactly.  :)

We should probably divvy up the output of CFC into [at least] two directories:

    $out_dir/
    |
    |-- include/
    |
    |-- source/


*All* .h files autogenenerated off of .cfh files -- whether those .cfh files
were found in an "include" or a "source" dir, would end up in $out_dir/include.

The only compilable source code files would be generated off of .cfh files
which were found via CFCHierarchy_add_source_dir(); these would go into
$out_dir/source.

It might also make sense to have the CFC::Binding::Perl object write all of
its output into subdirectories of $out_dir/ instead of directly into the Perl
lib/ dir.  That means an extra step for client code like Lucy::Build to copy
the autogenerated files to their destinations in lib/, but it's more
consistent behavior for CFC.

(I foresee a potential problem down the road when CFC finds so many .cfh files
that memory consumption blows up from trying to build them all at once -- but
this ought to be a solvable problem we can put off till later.)

> Maybe we should also add a CFCFile pointer to CFCClass.

I think that's a circular reference, though we can break it in the destructor
for the containing CFCHierarchy object so that we don't leak memory.  (FYI,
there are some existing refcount leaks in CFC right now that I have not yet
tracked down.)

We might also get away with a flag on CFCClass indicating whether it's
include-only, but a CFCFile pointer could work too.

> I hope this all makes sense.

Makes plenty of sense to me, and hopefully incrementally increasing amounts of
sense to you and others.  :)

Marvin Humphrey

Mime
View raw message