On Fri, Nov 28, 2014 at 5:22 AM, Nick Wellnhofer <[email protected]> wrote:
> 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. For what it's worth, that's what Go does. > 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. So, the effect will be to make it impractical to start a Clownfish project without the bootstrapping tool. I suppose for something like Clownfish in its present form, that's not unreasonable. Let's go with your plan. I can't help but wish that single-file Clownfish projects were possible, and it bothers me to move away from that. But if the Clownfish virtual machine succeeds in the marketplace, eventually there could be dedicated programming languages which run on top of it -- filling that niche more elegantly than we could hope to given the constraints we're working under to build a runtime with a C API. >>> 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. Now that you mention it, using a fixed name is simpler not only for tooling implementation, but also for humans reasoning about the system: the name "parcel.json" communicates purpose and data format in a way that "cfp file" does not. +1 for standardizing on "parcel.json". >>> 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. I suppose that's true. +1 for the convention of a "test" folder at the top level to hold core tests. We'll need some unusual load-time logic for running core tests under dynamic hosts. I'd also like to standardize on the dir we use for host-specific C code instead of having `perl/xs/`, `c/src/`, etc. How about defaulting to `cfext`? That shouldn't collide with anybody. >> 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 Glad we're on the same page about that! Outputting .a files from CFC should simplify build scripts for Clownfish-powered extensions -- it's easier to supply linker flags than to persuade the host build environment to do the right thing with C files scattered accross multiple directories requiring different compiler flags. Marvin Humphrey
