[Vm-dev] reorganizing opensmalltalk-vm
Ben Coman
btc at openinworld.com
Fri Oct 26 03:54:15 UTC 2018
Just a few thoughts. Take with a grain of salt.
On Fri, 26 Oct 2018 at 01:31, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi All,
>
> efforts are underway to include the VMMaker source in the
> opensmalltalk-vm repository.
>
Very nice.
> I'm hoping to see all the Smalltalk source included in the Tonel format
> (one file per class, and one file per extended class), with support for
> Pharo and Squeak quite soon. This is therefore an opportunity to also
> reorganize the structure of the repository to have a more comprehensible
> and less cluttered top-level directory. I'm interested in people's ideas.
> here are two suggestions.
>
> 1. move all source under src and all builds under build. So
> src/smalltalk/ all the VMMaker-related packages
> AioPlugin
> BytecodeSets
> Cog
> VMMaker
>
Could you explain what would be in VMMaker?
I thought all the plugins were a part of VMMaker rather than siblings.
i.e. why not src/vmmaker/AioPlugin & src/vmmaker/vm (or src/vmmaker/Core)
Also what would be in Cog? just the JIT stuff?
> src/generated/ all the generated code
> plugins/ all generated plugins
> v3 the V3 VM (now src/vm)
>
spur32 the 32-bit Spur VM (now spursrc/vm)
> spur64 the 64-bit Spur VM (now spur64src/vm)
>
Those renames definitely add clarity and will help newcomers, particularly
the v3 one.
However I think "src" should just be for "raw" sources.
A top level "generated" folder per your point[2.] would be good, but
perhaps also sllmming the name down to "gensrc".
src/platforms the current platforms directory
> src/third-party/
>
processors
>
Can "src" be kept just for "our" sources ?
IIUC, processors/IA32 contains third-party source folder "bochs"
as well our our code which looks like build script in folders
"$(PLATFORM)bochs"
Ideally that part should be split out under the build folder, and the
perhaps the third-party source goes under root folder "othersrc"
but the existing "processors" folder as a whole is not getting in the way,
so for now leave it.
Though the term "processors" has broad meaning and it may make more sense
to newcomers if the folder was "processor-sim" or "cpu-sim".
> build/ the current build directories
> macos32x86
> macos64x64
> deploy/
> image/
>
Maybe an idea for the future, "image" could be much more than just holding
scripts to create the build.image.
Initially it could hold image-side code for CI testing of the VM.
But also it seed the growth of a common image-side codebase for the low
level stuff between distributions.
Pharo's plan is to modularize things to build their shipping image from
multiple repositories,
so it shouldn't matter to them if their bootstrap pulls some parts direct
from opensmalltalk.
Or maybe it would be better to have all that in a different repo
https://github.com/OpenSmalltalk/opensmalltalk-image
In any case, "image" as things currently stand feels a bit odd at the
top-level.
It seems it would fit better under "scripts/image", or "scripts/dev.image"
btw, what is spec/locode.xml ?
Is that something loaded by the image-side by a user?
That might fit under image/specs/lowcode.xml ?
> tests/
>
> 2. single top-level directories for generated source, and Smalltalk
> source, everything else unchanged
> smalltalksrc/ all the VMMaker-related packages
> generatedsrc/ all the generated code as above in src/generated,
> but in generatedsrc instead
>
platforms
> processors
> third-party
> tests
> deploy
>
> Obviously #1 is more work but produces a much cleaner structure. Other
> suggestions? Reactions to the above?
> _,,,^..^,,,_
> best, Eliot
>
3. So top level could look like...
src/ our own root sources, native and smalltalk VMMaker
gensrc/ generated from VMMaker
othersrc/ third-party libs kept intree (manually or via subtree
or submodule)
cachesrc/ sources downloaded during build (empty folder on github
except readme.md)
scripts/
build/
deploy/
with second level...
src/smalltalk/ all the VMMaker-related packages
src/platforms the current platforms directory
src/third-party/ only the spec files
The main readme says "Another distinction is between Stack, Cog and Sista
VMs",
so would it be better to be explicit about which ones are Cog?
Also would it be better to be explicit about v3 only being 32 bit (if I
guess correctly)
gensrc/plugins
gensrc/v3cog32 old src
gensrc/v3stack32 old stacksrc
gensrc/spurstack32 old spurstacksrc
gensrc/spurstack64 old spurstack64src
gensrc/spurcog32 old spursrc
gensrc/spurcog64 old spur64src
gensrc/spursista32 old spursista64src
gensrc/spursista64 old spursista64src
gensrc/spurlowcode32 old spurlowcodesrc
gensrc/spurlowcode64 old spurlowcode64src
othersrc/gdb
othersrc/bochs an alternative is to mirror/fork bochs into
opensmalltalk-vm/bochs and have a build script pull that to your machine
e.g.
https://github.com/search?q=bochs+mirror&type=Repositories
you can have one branch called
"mirror" that only *ever* sucks from upstream
with any custom mods in a branch
called "Cog".
scripts/ci
scripts/image
scripts/git
build/linuxXXX
build/winXXX
deploy/squeak
deploy/pharo
deploy/newspeak
cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181026/07da70b5/attachment-0001.html>
More information about the Vm-dev
mailing list