On 26/11/2014 23:35, Marvin Humphrey wrote:
As noted earlier: Requiring that the contents within "include" directories
adhere to such strict naming conventions is fine for installers but unfriendly
to development.
So instead, how about applying this ruleset to every top level directory in
either "source" or "include"?
1. If we can detect that a given directory follows the naming convention
PARCEL-VERSION, extract the parcel name from the dir name.
2. Otherwise look for a .cfp file at the top level.
3. Otherwise, parse every Clownfish file in the tree. There should be only
one parcel specified.
I think this would allow us to form a unified array of search paths consisting
of all "source" dirs followed by all "include" dirs. (Is there any reason we
need to continue distinguising between the "source" and "include" for
search-path purposes?)
An important use case is a minimal single-parcel project, which should be
possible using only a single directory and two loose files:
core/MyProject.cfh # declares `parcel com.example.foo`
core/MyProject.c
On installation, the tool would assume version "0" in the absence of a parcel
file.
_include/com.example.foo-0/
_include/com.example.foo-0/MyProject.cfh
Sound sane?
I think every parcel needs to have a .cfp file to tell which version of the
Clownfish runtime it depends on. So the Clownfish compiler could simply walk
the source directories, and as soon as it finds a .cfp file, it can make all
files in that directory part of this parcel.
If we enforce that all files of a parcel live under a single directory, we can
also make the following simplifications:
1. There's no need for `parcel` directives in .cfh files anymore. This would
remove a bit of boilerplate.
2. .cfp files don't need a unique filename. They could be simply named
`parcel.json`, for example.
Another consequence is that we either need another directory level under
`core` for Lucy and Clownfish because of the test parcels:
core/lucy/Lucy/Analysis
core/test/Lucy/Test/TestAnalysis
Or we put the tests in a separate top-level directory:
core/Lucy/Analysis
test/Lucy/Test/TestAnalysis
Regarding the include directory layout, maybe we should make a change to my
original proposal inspired by Ruby gems. Instead of putting a parcel's file in
a directory named `parcel-version`, we could create single directory for all
versions of a parcel with subdirectories for each version like:
include/com.example.foo/1.0.0/parcel.json
include/com.example.foo/2.0.0/parcel.json
So we wouldn't have to read the whole top-level directory to lookup parcels.
Whether a parcel exists can be decided with a single `stat` call. To find all
the versions of a parcel, only the entries in the parcel's subdirectory have
to be consulted.
Nick
