[Vm-dev] Proposal | Clean-up source tree's *src folders

Tue Jul 13 11:27:10 UTC 2021

Hi Marcel,

With regards to the ordinariness I specifically also mean the
implementation, not only how you operate it as long as nothing breaks. If
you want to adapt the build system in the future, any custom-made solution
will be an obstacle. In the mildest form it will simply cost time to
understand and assess. In the severest form it will be a blocker and a
deterrent.

I have nothing against simplifying the top level directory. I just cast my
vote against the symlinks :-) Unless you demonstrate that it will be easier
to understand and more ordinary with than without them.

Kind regards,
Jakob

Am Di., 13. Juli 2021 um 13:17 Uhr schrieb Marcel Taeumel <
marcel.taeumel at hpi.de>:

>
> Hi Jakob,
>
> I think that you are mixing up "interface" and "implementation" of our
> build system here. I wouldn't want to change any "interface", e.g. "./mvm
> -f" for Windows builds or its direkt Makefile variant. The build-system's
> "implementation" can be improved without breaking existing workflows. :-)
>
> > Newcomers should not be overwhelmed by any more extraordinariness [...]
>
> That's exactly why I think that there are too many *src folder on the
> toplevel.
>
> > In my opinion the build should work as "ordinarily" as possible in comparison
> to other FOSS builds.
>
> Well, this is no ordinary FOSS project. So, we might want to find good -
> and better - trade-offs here. ;-)
>
> Best,
> Marcel
>
> Am 13.07.2021 13:11:21 schrieb Jakob Reschke <jakres+squeak at gmail.com>:
> Hi Marcel,
>
> In my opinion the build should work as "ordinarily" as possible in
> comparison to other FOSS builds. Newcomers should not be overwhelmed by
> any more extraordinariness than there already is because of the Slang
> generation, updateSCCSVersions, hand-written makefiles plus scripts,
> plugin
> lists etc. Being ordinary should also simplify ports and build
> refactorings. I think that relying on symlinks would be one step further
> away from being ordinary.
>
> Kind regards,
> Jakob
>
>
> Am Di., 13. Juli 2021 um 10:53 Uhr schrieb Marcel Taeumel <
> marcel.taeumel at hpi.de>:
>
> >
> > Hmm... all of our build systems are able to create symlinks, right?
> > Couldn't we just create that "src/vm" symlink to point to the particular
> > flavor? Hmm....
> >
> > Am 13.07.2021 09:38:36 schrieb Marcel Taeumel :
> > Ah, I noticed the pattern "../../platforms" (or similar). Well, by
> > flattening the sources one level, that pattern would still work.
> >
> >
> > Best,
> > Marcel
> >
> > Am 13.07.2021 09:22:24 schrieb Marcel Taeumel :
> > Please find attached a change set for VMMaker and a screenshot of what
> the
> > src folder would look like. A diff for all build files will follow soon
> > here on this list.
> >
> >
> >
> > Best,
> > Marcel
> >
> > Am 13.07.2021 08:49:24 schrieb Marcel Taeumel :
> > Hi all!
> >
> > I would like to clarify (or re-arrange) the structure of the source tree
> > so that we can continue to work on existing and experiment on new
> flavors
> > of the VM. They would then better match our build structure:
> >
> > /src/plugins -> (same)
> >
> > /src/vm -> /src/vm.32bit.cog.v3
> > /stacksrc/vm -> /src/vm.32bit.stack.v3
> >
> > /spurstacksrc/vm -> /src/vm.32bit.stack.spur
> > /spurstack64src/vm -> /src/vm.64bit.stack.spur
> > /spursrc/vm -> /src/vm.32bit.cog.spur
> > /spur64src/vm -> /src/vm.64bit.cog.spur
> > /spursistasrc/vm -> /src/vm.32bit.sista.spur
> > /spursista64src/vm -> /src/vm.64bit.sista.spur
> >
> > /nsspurstacksrc/vm -> /src/newspeak.vm.32bit.stack.spur
> > /nsspurstack64src/vm -> /src/newspeak.vm.64bit.stack.spur
> > /nsspursrc/vm -> /src/newspeak.vm.32bit.cog.spur
> > /nsspur64src/vm -> /src/newspeak.vm.64bit.cog.spur
> >
> > /spurlowcodestacksrc/vm -> /src/lowcode.vm.32bit.stack.spur
> > /spurlowcodestack64src/vm -> /src/lowcode.vm.64bit.stack.spur
> > /spurlowcodesrc/vm -> /src/lowcode.vm.32bit.cog.spur
> > /spurlowcode64src/vm -> /src/lowcode.vm.64bit.cog.spur
> >
> > This would make 15 different *src folders disappear from the source
> tree's
> > toplevel. Flavor-specific plugin lists might be defined from within
> VMMaker
> > and generated into their respective src folders.
> >
> > Also, there would be a clear place for /src/vm.32bit.interpreter.v3 too
> > :-)
> >
> > Thoughts? Opinions? Objections?
> >
> > Best,
> > Marcel
> >
> >
> Hi Marcel,
>
> In my opinion the build should work as "ordinarily" as possible in
> comparison to other FOSS builds.  Newcomers should not be overwhelmed by
> any more extraordinariness than there already is because of the Slang
> generation, updateSCCSVersions, hand-written makefiles plus scripts, plugin
> lists etc.  Being ordinary should also simplify ports and build
> refactorings.  I think that relying on symlinks would be one step further
> away from being ordinary.
>
> Kind regards,
> Jakob
>
>
> Am Di., 13. Juli 2021 um 10:53 Uhr schrieb Marcel Taeumel <
> marcel.taeumel at hpi.de>:
>
>>
>>
>> Hmm... all of our build systems are able to create symlinks, right?
>> Couldn't we just create that "src/vm" symlink to point to the particular
>> flavor? Hmm....
>>
>>
>> Am 13.07.2021 09:38:36 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
>>
>> Ah, I noticed the pattern "../../platforms" (or similar). Well, by
>> flattening the sources one level, that pattern would still work.
>>
>>
>> Best,
>> Marcel
>>
>>
>> Am 13.07.2021 09:22:24 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
>>
>> Please find attached a change set for VMMaker and a screenshot of what
>> the src folder would look like. A diff for all build files will follow soon
>> here on this list.
>>
>>
>>
>> Best,
>> Marcel
>>
>>
>> Am 13.07.2021 08:49:24 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
>> Hi all!
>>
>> I would like to clarify (or re-arrange) the structure of the source tree
>> so that we can continue to work on existing and experiment on new flavors
>> of the VM. They would then better match our build structure:
>>
>> /src/plugins -> (same)
>>
>> /src/vm -> /src/vm.32bit.cog.v3
>> /stacksrc/vm -> /src/vm.32bit.stack.v3
>>
>> /spurstacksrc/vm -> /src/vm.32bit.stack.spur
>> /spurstack64src/vm -> /src/vm.64bit.stack.spur
>> /spursrc/vm -> /src/vm.32bit.cog.spur
>> /spur64src/vm -> /src/vm.64bit.cog.spur
>> /spursistasrc/vm -> /src/vm.32bit.sista.spur
>> /spursista64src/vm -> /src/vm.64bit.sista.spur
>>
>> /nsspurstacksrc/vm -> /src/newspeak.vm.32bit.stack.spur
>> /nsspurstack64src/vm -> /src/newspeak.vm.64bit.stack.spur
>> /nsspursrc/vm -> /src/newspeak.vm.32bit.cog.spur
>> /nsspur64src/vm -> /src/newspeak.vm.64bit.cog.spur
>>
>> /spurlowcodestacksrc/vm -> /src/lowcode.vm.32bit.stack.spur
>> /spurlowcodestack64src/vm -> /src/lowcode.vm.64bit.stack.spur
>> /spurlowcodesrc/vm -> /src/lowcode.vm.32bit.cog.spur
>> /spurlowcode64src/vm -> /src/lowcode.vm.64bit.cog.spur
>>
>> This would make 15 different *src folders disappear from the source
>> tree's toplevel. Flavor-specific plugin lists might be defined from within
>> VMMaker and generated into their respective src folders.
>>
>> Also, there would be a clear place for /src/vm.32bit.interpreter.v3 too
>> :-)
>>
>> Thoughts? Opinions? Objections?
>>
>> Best,
>> Marcel
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210713/d89c0c44/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 28911 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210713/d89c0c44/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 173140 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210713/d89c0c44/attachment-0003.png>