On 23/03/2012 02:49, Marvin Humphrey wrote:
On Thu, Mar 22, 2012 at 12:10 PM, Nick Wellnhofer<[email protected]> wrote:
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.
This is now implemented in the branch.
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.
Also done.
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 used a flag ('is_included') and didn't go with the CFCFile pointer
approach.
With these changes I was able to compile and link a test extension in an
external tree, although some things aren't working yet or needed manual
adjustments.
One thing is core/Lucy/Util/ToolSet.h, which is included from every
Clownfish .c file. I'm not sure what's the best way to handle that.
Then the whole autobinding stuff doesn't work correctly yet. I only had
a quick glance at the relevant code, but it seems that some parts of
Clownfish are still hardcoded to Lucy.
Nick
