On Wed, Jul 31, 2013 at 11:57 AM, Nick Wellnhofer <[email protected]> wrote:
> Travis CI discovered another build failure:
>
> https://travis-ci.org/theory/lucy/jobs/9451089
>
> The reason is that the order of #includes in the autogenerated file
> callbacks.h is random, and for this build, the first included file seems to
> be Lucy/Test/Store/TestFolderCommon.h. The corresponding .cfh file happens
> to start with a Clownfish "C block" which relies on the forward declarations
> in lucy_parcel.h which has not been included yet. I can see the following
> solutions:
>
> 1. Generate an #include directive for every .cfh parcel definition.
>
> 2. Always include the parcel.h files for all dependencies of a generated
> header file first.
>
> I prefer the first solution. Thoughts?
C blocks are a heinous hack that I wish we could do without. For now, they're
an essential safety valve for a few features that are too complex to
implement directly in the Clownfish header language, but a part of me would
like to have them undocumented in the initial release in the faint hope that
we could get away with removing them eventually. I anticipate that
supporting them will constrain our ability to evolve Clownfish.
I think the fix in this particular case is minimal. This ought to do it,
right?
--- a/core/Lucy/Test/Store/TestFolderCommon.cfh
+++ b/core/Lucy/Test/Store/TestFolderCommon.cfh
@@ -17,7 +17,7 @@
parcel TestLucy;
__C__
-typedef lucy_Folder*
+typedef struct lucy_Folder*
Lucy_TestFolderCommon_Set_Up_t(void);
typedef void
Lucy_TestFolderCommon_Tear_Down_t(void);
I don't think we should go out of our way to accommodate C blocks at all.
Experts only, and only when there's no other recourse.
Marvin Humphrey
