On 27/11/2014 22:33, Marvin Humphrey wrote:
On Wed, Nov 26, 2014 at 3:25 PM, Nick Wellnhofer <[email protected]> wrote:
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.
I'm not sure you were implying this, but a parcel file should not apply to
directories above it. Parcel files should only be allowed in the
primary parcel dir.
Sorry for being unclear. I meant that only files below the directory where the
.cfp file is found should be part of the parcel.
1. There's no need for `parcel` directives in .cfh files anymore. This would
remove a bit of boilerplate.
Both Python and Go base organize packages around directories, but while Go
requires package directives in every source file, Python doesn't. So there
are precedents or both approaches.
If we'd keep the `parcel` directives, we should check that they match the
parcel from the .cfp file. This seems like an unnecessary complication.
I maintain that it's important that parcel files not be mandatory. If there's
no parcel file and no parcel directive in any source files, what should the
behavior be? Default to parcel "main" version 0? If so, what does that imply
when someone attempts to install something from parcel "main"?
I think it's a bad idea to install a parcel that doesn't declare on which
Clownfish version it depends. For simple testing, we could use a default parcel.
But the .cfp file could simply be generated using the project bootstrapping
tool we already discussed. So I don't see why we shouldn't make it mandatory.
2. .cfp files don't need a unique filename. They could be simply named
`parcel.json`, for example.
We've decided to avoid the nested directory problem of Java, but a side effect
is that you can't necessarily discover the parcel by looking at the file
system -- at least in a "source" directory.
So, while I agree that unique names are not technically necessary, I'm not
jumping up and down with enthusiasm about normalizing them all to
`parcel.json`.
Having a fixed filename would simplify things a bit. But I can live with .cfp
files.
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
That's one approach. If test code remains in a separate parcel, though, the
problem of test code not being able to access non-exported symbols from the
main parcel has yet to be resolved.
Does it? As long as the test parcel is linked into the same binary, there
shouldn't be a problem.
Let me float another possibility: test code belongs to the same parcel and
lives in the same directory as the parcel source code, but test files are
distinguished by a naming convention such as beginning with the string "Test".
Two versions of the parcel library are linked: a test version with all the
test file objects included, and an installation version with the test objects
excluded.
I agree that compiling two versions of a library seems like the best approach
to solve the long-standing issue of creating binaries without all the test
code. But this should work with a separate test parcel as well. I don't want
to remove the feature to link multiple parcels into a single library.
Let me also float a possibility I've been thinking about for a while, which is
that the output of CFC should be static archives plus headers, rather than C
source code plus headers. Perhaps that opens up some options for dealing with
test files.
+1
Nick
