On Dec 16, 2013, at 04:58 , Marvin Humphrey <[email protected]> wrote:
> Perhaps we might triage away these items for later?
>
>> * Better handling of C flags in the build process
I already started to work on this but currently I’m blocking on the
Lucy/Clownfish separation of the Perl build.
>> * Explicit dependencies for Clownfish parcels
I think this would be nice to have before release, at least in a rudimentary
form. For example, if the necessary Clownfish headers for a project aren’t
found, the following happens right now:
$ make
cfc --source=../core --dest=autogen --header=cfc_header
No class found for type 'String'
make: *** [autogen] Error 1
This doesn’t really help to figure out what went wrong. If we had explicit
dependencies, the Clownfish compiler would notice that Clownfish.cfp is
required but missing and print a better error message:
Parcel ‘Clownfish’ not found in Clownfish include directories:
(list of include directories)
We could also run cfc in a ‘probe’ mode during configuration which simply
checks for the .cfp file of a parcel and all its dependencies:
cfc --probe-parcel Clownfish
If this fails, we could point the user to the INSTALL file. For now, it might
be enough to implement probes for a single parcel without dependency checks.
This should be really easy.
>> * Separate tests
Yes, this can be put off.
> Here are some items I suggest we add to the TODO list:
>
> * Develop a plan for how we'll evolve the API after launch. (Language Spec
> for Clownfish? Backwards compatibility? Avoiding bloat characteristic of
> Apache-style governance? Clownfish Enhancement Proposals approved by the
> PMC a la Python PEPs?)
> * Develop a marketing strategy. (Website? Whitepaper? Conference talks?
> Logo? Incubator? Who is the target market and how will we reach out?)
> * Review the lucy-dev list archives for technical concerns and open a bunch
> of tickets.
> * Clownfish Tutorial.
+1 to all of these.
Nick
