[Vm-dev] VM packaging for Cog transition

Bert Freudenberg bert at freudenbergs.de
Tue Nov 9 10:25:53 UTC 2010

On 09.11.2010, at 03:44, Andreas Raab wrote:

> On 11/8/2010 5:39 PM, David T. Lewis wrote:
>> On Mon, Nov 08, 2010 at 11:43:50AM -0800, Andreas Raab wrote:
>>> On 11/8/2010 3:35 AM, David T. Lewis wrote:
>>>> To be clear, the intent is to provide both Cog and the interpreter VM.
>>> Agree. I think the first step is to unify the support code. I.e., when
>>> it's all said and done we should have a structure roughly along the
>>> lines of:
>>> platforms/
>>> 	Cross/
>>> 	Unix/
>>> 	Mac/
>>> 	Win/
>>> src-interp/
>>> src-jit/
>>> etc. and the *only* difference should be in the src-interp vs. src-jit
>>> directories. In which case we can decide what to build based on the
>>> selecting the appropriate interp/jit source directory.
>> To check my understanding, you are suggesting that the src-interp and
>> src-jit directories would be for the generated sources, as distinct
>> from the platform support code under platforms/...  and that the structure
>> of the platforms/... tree would remain unchanged. Is that right?
> Exactly. Most importantly the platforms support code would be *identical* across the variants and thus eliminate further proliferation of various bits of C code.
> Cheers,
>  - Andreas

I'd love to have this structure. Making the platform names more uniform is good. Though I'd retain the space in "Mac OS" because many files in that subtree contain spaces, and it's a visible reminder of that.

Shouldn't we have a single folder for generated plugins? Also, I always felt that "src" was misleading. So how about this:

	Mac OS/

However, one reason to put the generated sources inside the platform folders was because often the platform code lagged behind, and only the single maintainer could fix it. A better solution to that would be opening up VM development. As I mentioned before I'd like us to move to a DCVS. If we intend to change the repository structure this would be an excellent time.

- Bert -

More information about the Vm-dev mailing list