Platforms Layout?

Hi:

I am trying to understand the principle behind the layout of the directory structure of the platforms source directory of the VM.

Is there some document which describes the rational behind the code organization?

On the top level, I see the different platforms (Cross - for cross-platform code, win32, Mac OS, unix, etc...) which makes sense to me.
However, when I start to look for instance into the unix folder, it starts to get, well, messy, or at least, I don't get what I see there.

Why is there a src folder on the same level with a vm folder, and vm-(display|sound)-* folders?

Would be great if someone could guide me a bit.
I will probably try to get the code of the RoarVM organized in a similar way, however, for that, I will need to understand what goes where.

Probably related, I seem to remember a discussion on change the layout of that directory structure a while back, but did not find it.

Thanks
Stefan

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

On 11.04.2011, at 23:29, Stefan Marr wrote:

src contains the code generated from the Smalltalk sources. It is included for bootstrapping so that users can easily build a VM from source.

It is not shared between platforms because they are not always updated at the same pace. Platforms frequently got out of sync so it was simpler to just include the generated sources in the repository.

- Bert -

Dear Stefan,

On Apr 12, 2011, at 06:29 , Stefan Marr wrote:

> I am trying to understand the principle behind the layout of the directory structure of the platforms source directory of the VM.
>
> Is there some document which describes the rational behind the code organization?

I'm not sure you'll find much that could be called "principle" here, but try this:

http://wiki.squeak.org/squeak/2105

Regards,
Ian

Hi Ian:

On 12 Apr 2011, at 01:59, Ian Piumarta wrote:

> I'm not sure you'll find much that could be called "principle" here, but try this:
>
> http://wiki.squeak.org/squeak/2105
Thanks, that gives some overview, but I fear the current repository structure is, ehm, evolved.

And I have the strong urge to refactor the structure.

In case there is some interest from the VM people, maybe it would be possible to come up with some common structure we all can live with.

Important properties for me would be:
 - separate build infrastructure, not intermingled with the code
   I think, currently the SqueakVM uses cmake, and I hope that is platform independent.
   The iOS Squeak VM uses Xcode projects, but I hope that could also be organized a bit more, ehm, careful too.
 - separate directory for the generated code
   so that either the SqueakVM code can be generated into it, or the RoarVM code is just present there for instance
 - other resource would ideally also separated, so that I can just grab the essential parts and don't need to worry about the rest, when I sync code with the RoarVM.

Bye the way, in the unix folder, the vm-display* and vm-sound* things, are those plugins?
Do they related somehow to plugins, or is that really something that belongs where it is currently?

Thanks
Stefan


>
> Regards,
> Ian
>

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

On 12.04.2011, at 19:20, Stefan Marr wrote:
>
> Bye the way, in the unix folder, the vm-display* and vm-sound* things, are those plugins?

They are parts of the VM that are dynamically loaded. In that sense they are plugins, but not like the other plugins (which are properly called Squeak modules, but everyone uses the term "plugins").

Instead, they provide alternative implementations for basic VM functionality like display and sound output. Those need to be loaded dynamically depending on the user's system.

> Do they related somehow to plugins, or is that really something that belongs where it is currently?

In contrast to "regular" plugins they do not implement primitives.

- Bert -