<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Jakob.<div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Unless you demonstrate that it will be easier </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">to understand and more ordinary with than without them.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Currently, we have a lot of stuff (outside our central build system) pointing to "src/vm", which means that that broke the first time we started to use "spursrc" etc. The use of symlinks to simplify the build system is not a new idea in the history of the SqueakVM. Currently, I am still browsing and just entertaining the thought that a symlink behind "src/vm" might help to some extent.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Yes, the alternative is to just find-and-replace the entries in the table I posted at the beginning. Well, "src/vm" might not match "src/vm.32bit.cog.v3" on all occasions. Yet, this affects artfiacts that are apparently no longer used. I have to double-check the dependencies of the plain interpreter VM (non-oscog).</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 13.07.2021 13:27:32 schrieb Jakob Reschke <jakres+squeak@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif"> Hi Marcel,
<br>
<br>With regards to the ordinariness I specifically also mean the
<br>implementation, not only how you operate it as long as nothing breaks. If
<br>you want to adapt the build system in the future, any custom-made solution
<br>will be an obstacle. In the mildest form it will simply cost time to
<br>understand and assess. In the severest form it will be a blocker and a
<br>deterrent.
<br>
<br>I have nothing against simplifying the top level directory. I just cast my
<br>vote against the symlinks :-) Unless you demonstrate that it will be easier
<br>to understand and more ordinary with than without them.
<br>
<br>Kind regards,
<br>Jakob
<br>
<br>Am Di., 13. Juli 2021 um 13:17 Uhr schrieb Marcel Taeumel <
<br>marcel.taeumel@hpi.de>:
<br>
<br>>
<br>> Hi Jakob,
<br>>
<br>> I think that you are mixing up "interface" and "implementation" of our
<br>> build system here. I wouldn't want to change any "interface", e.g. "./mvm
<br>> -f" for Windows builds or its direkt Makefile variant. The build-system's
<br>> "implementation" can be improved without breaking existing workflows. :-)
<br>>
<br>> > Newcomers should not be overwhelmed by any more extraordinariness [...]
<br>>
<br>> That's exactly why I think that there are too many *src folder on the
<br>> toplevel.
<br>>
<br>> > In my opinion the build should work as "ordinarily" as possible in comparison
<br>> to other FOSS builds.
<br>>
<br>> Well, this is no ordinary FOSS project. So, we might want to find good -
<br>> and better - trade-offs here. ;-)
<br>>
<br>> Best,
<br>> Marcel
<br>>
<br>> Am 13.07.2021 13:11:21 schrieb Jakob Reschke <jakres+squeak@gmail.com>:
<br>> Hi Marcel,
<br>>
<br>> In my opinion the build should work as "ordinarily" as possible in
<br>> comparison to other FOSS builds. Newcomers should not be overwhelmed by
<br>> any more extraordinariness than there already is because of the Slang
<br>> generation, updateSCCSVersions, hand-written makefiles plus scripts,
<br>> plugin
<br>> lists etc. Being ordinary should also simplify ports and build
<br>> refactorings. I think that relying on symlinks would be one step further
<br>> away from being ordinary.
<br>>
<br>> Kind regards,
<br>> Jakob
<br>>
<br>>
<br>> Am Di., 13. Juli 2021 um 10:53 Uhr schrieb Marcel Taeumel <
<br>> marcel.taeumel@hpi.de>:
<br>>
<br>> >
<br>> > Hmm... all of our build systems are able to create symlinks, right?
<br>> > Couldn't we just create that "src/vm" symlink to point to the particular
<br>> > flavor? Hmm....
<br>> >
<br>> > Am 13.07.2021 09:38:36 schrieb Marcel Taeumel :
<br>> > Ah, I noticed the pattern "../../platforms" (or similar). Well, by
<br>> > flattening the sources one level, that pattern would still work.
<br>> >
<br>> >
<br>> > Best,
<br>> > Marcel
<br>> >
<br>> > Am 13.07.2021 09:22:24 schrieb Marcel Taeumel :
<br>> > Please find attached a change set for VMMaker and a screenshot of what
<br>> the
<br>> > src folder would look like. A diff for all build files will follow soon
<br>> > here on this list.
<br>> >
<br>> >
<br>> >
<br>> > Best,
<br>> > Marcel
<br>> >
<br>> > Am 13.07.2021 08:49:24 schrieb Marcel Taeumel :
<br>> > Hi all!
<br>> >
<br>> > I would like to clarify (or re-arrange) the structure of the source tree
<br>> > so that we can continue to work on existing and experiment on new
<br>> flavors
<br>> > of the VM. They would then better match our build structure:
<br>> >
<br>> > /src/plugins -> (same)
<br>> >
<br>> > /src/vm -> /src/vm.32bit.cog.v3
<br>> > /stacksrc/vm -> /src/vm.32bit.stack.v3
<br>> >
<br>> > /spurstacksrc/vm -> /src/vm.32bit.stack.spur
<br>> > /spurstack64src/vm -> /src/vm.64bit.stack.spur
<br>> > /spursrc/vm -> /src/vm.32bit.cog.spur
<br>> > /spur64src/vm -> /src/vm.64bit.cog.spur
<br>> > /spursistasrc/vm -> /src/vm.32bit.sista.spur
<br>> > /spursista64src/vm -> /src/vm.64bit.sista.spur
<br>> >
<br>> > /nsspurstacksrc/vm -> /src/newspeak.vm.32bit.stack.spur
<br>> > /nsspurstack64src/vm -> /src/newspeak.vm.64bit.stack.spur
<br>> > /nsspursrc/vm -> /src/newspeak.vm.32bit.cog.spur
<br>> > /nsspur64src/vm -> /src/newspeak.vm.64bit.cog.spur
<br>> >
<br>> > /spurlowcodestacksrc/vm -> /src/lowcode.vm.32bit.stack.spur
<br>> > /spurlowcodestack64src/vm -> /src/lowcode.vm.64bit.stack.spur
<br>> > /spurlowcodesrc/vm -> /src/lowcode.vm.32bit.cog.spur
<br>> > /spurlowcode64src/vm -> /src/lowcode.vm.64bit.cog.spur
<br>> >
<br>> > This would make 15 different *src folders disappear from the source
<br>> tree's
<br>> > toplevel. Flavor-specific plugin lists might be defined from within
<br>> VMMaker
<br>> > and generated into their respective src folders.
<br>> >
<br>> > Also, there would be a clear place for /src/vm.32bit.interpreter.v3 too
<br>> > :-)
<br>> >
<br>> > Thoughts? Opinions? Objections?
<br>> >
<br>> > Best,
<br>> > Marcel
<br>> >
<br>> >
<br>> Hi Marcel,
<br>>
<br>> In my opinion the build should work as "ordinarily" as possible in
<br>> comparison to other FOSS builds.  Newcomers should not be overwhelmed by
<br>> any more extraordinariness than there already is because of the Slang
<br>> generation, updateSCCSVersions, hand-written makefiles plus scripts, plugin
<br>> lists etc.  Being ordinary should also simplify ports and build
<br>> refactorings.  I think that relying on symlinks would be one step further
<br>> away from being ordinary.
<br>>
<br>> Kind regards,
<br>> Jakob
<br>>
<br>>
<br>> Am Di., 13. Juli 2021 um 10:53 Uhr schrieb Marcel Taeumel <
<br>> marcel.taeumel@hpi.de>:
<br>>
<br>>>
<br>>>
<br>>> Hmm... all of our build systems are able to create symlinks, right?
<br>>> Couldn't we just create that "src/vm" symlink to point to the particular
<br>>> flavor? Hmm....
<br>>>
<br>>>
<br>>> Am 13.07.2021 09:38:36 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:
<br>>>
<br>>> Ah, I noticed the pattern "../../platforms" (or similar). Well, by
<br>>> flattening the sources one level, that pattern would still work.
<br>>>
<br>>>
<br>>> Best,
<br>>> Marcel
<br>>>
<br>>>
<br>>> Am 13.07.2021 09:22:24 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:
<br>>>
<br>>> Please find attached a change set for VMMaker and a screenshot of what
<br>>> the src folder would look like. A diff for all build files will follow soon
<br>>> here on this list.
<br>>>
<br>>>
<br>>>
<br>>> Best,
<br>>> Marcel
<br>>>
<br>>>
<br>>> Am 13.07.2021 08:49:24 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:
<br>>> Hi all!
<br>>>
<br>>> I would like to clarify (or re-arrange) the structure of the source tree
<br>>> so that we can continue to work on existing and experiment on new flavors
<br>>> of the VM. They would then better match our build structure:
<br>>>
<br>>> /src/plugins -> (same)
<br>>>
<br>>> /src/vm -> /src/vm.32bit.cog.v3
<br>>> /stacksrc/vm -> /src/vm.32bit.stack.v3
<br>>>
<br>>> /spurstacksrc/vm -> /src/vm.32bit.stack.spur
<br>>> /spurstack64src/vm -> /src/vm.64bit.stack.spur
<br>>> /spursrc/vm -> /src/vm.32bit.cog.spur
<br>>> /spur64src/vm -> /src/vm.64bit.cog.spur
<br>>> /spursistasrc/vm -> /src/vm.32bit.sista.spur
<br>>> /spursista64src/vm -> /src/vm.64bit.sista.spur
<br>>>
<br>>> /nsspurstacksrc/vm -> /src/newspeak.vm.32bit.stack.spur
<br>>> /nsspurstack64src/vm -> /src/newspeak.vm.64bit.stack.spur
<br>>> /nsspursrc/vm -> /src/newspeak.vm.32bit.cog.spur
<br>>> /nsspur64src/vm -> /src/newspeak.vm.64bit.cog.spur
<br>>>
<br>>> /spurlowcodestacksrc/vm -> /src/lowcode.vm.32bit.stack.spur
<br>>> /spurlowcodestack64src/vm -> /src/lowcode.vm.64bit.stack.spur
<br>>> /spurlowcodesrc/vm -> /src/lowcode.vm.32bit.cog.spur
<br>>> /spurlowcode64src/vm -> /src/lowcode.vm.64bit.cog.spur
<br>>>
<br>>> This would make 15 different *src folders disappear from the source
<br>>> tree's toplevel. Flavor-specific plugin lists might be defined from within
<br>>> VMMaker and generated into their respective src folders.
<br>>>
<br>>> Also, there would be a clear place for /src/vm.32bit.interpreter.v3 too
<br>>> :-)
<br>>>
<br>>> Thoughts? Opinions? Objections?
<br>>>
<br>>> Best,
<br>>> Marcel
<br>>>
<br>>>
<br>>>
<br>>
<br><div dir="ltr">Hi Marcel,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Kind regards,<br>Jakob</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Di., 13. Juli 2021 um 13:17 Uhr schrieb Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>>:<br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex;border-left: 1px solid rgb(204,204,204);padding-left: 1ex;min-width: 500px"> <div id="gmail-m_-7017067204786552037__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: rgb(0,0,0);text-align: left" dir="ltr">
<br>                                        Hi Jakob,<div><br></div><div>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. :-)</div><div><br></div><div>> <span style="font-family: Arial,Helvetica,sans-serif;font-size: 13px">Newcomers should not be overwhelmed by </span><span style="font-family: Arial,Helvetica,sans-serif;font-size: 13px">any more extraordinariness [...]</span></div><div><br></div><div>That's exactly why I think that there are too many *src folder on the toplevel.</div><div><br></div><div>> <span style="font-family: Arial,Helvetica,sans-serif;font-size: 13px">In my opinion the build should work as "ordinarily" as possible in </span><span style="font-family: Arial,Helvetica,sans-serif;font-size: 13px">comparison to other FOSS builds.</span></div><div><br></div><div>Well, this is no ordinary FOSS project. So, we might want to find good - and better - trade-offs here. ;-)</div><div><br></div><div>Best,</div><div>Marcel</div><div></div>
<br>                                        <blockquote type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<br>                        <p style="color:rgb(170,170,170);margin-top:10px">Am 13.07.2021 13:11:21 schrieb Jakob Reschke <<a href="mailto:jakres%2Bsqueak@gmail.com" target="_blank">jakres+squeak@gmail.com</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"> Hi Marcel,
<br><br>
<br><br>In my opinion the build should work as "ordinarily" as possible in
<br><br>comparison to other FOSS builds.  Newcomers should not be overwhelmed by
<br><br>any more extraordinariness than there already is because of the Slang
<br><br>generation, updateSCCSVersions, hand-written makefiles plus scripts, plugin
<br><br>lists etc.  Being ordinary should also simplify ports and build
<br><br>refactorings.  I think that relying on symlinks would be one step further
<br><br>away from being ordinary.
<br><br>
<br><br>Kind regards,
<br><br>Jakob
<br><br>
<br><br>
<br><br>Am Di., 13. Juli 2021 um 10:53 Uhr schrieb Marcel Taeumel <
<br><br><a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>>:
<br><br>
<br><br>>
<br><br>> Hmm... all of our build systems are able to create symlinks, right?
<br><br>> Couldn't we just create that "src/vm" symlink to point to the particular
<br><br>> flavor? Hmm....
<br><br>>
<br><br>> Am 13.07.2021 09:38:36 schrieb Marcel Taeumel <u></u>:
<br><br>> Ah, I noticed the pattern "../../platforms" (or similar). Well, by
<br><br>> flattening the sources one level, that pattern would still work.
<br><br>>
<br><br>>
<br><br>> Best,
<br><br>> Marcel
<br><br>>
<br><br>> Am 13.07.2021 09:22:24 schrieb Marcel Taeumel <u></u>:
<br><br>> Please find attached a change set for VMMaker and a screenshot of what the
<br><br>> src folder would look like. A diff for all build files will follow soon
<br><br>> here on this list.
<br><br>>
<br><br>>
<br><br>>
<br><br>> Best,
<br><br>> Marcel
<br><br>>
<br><br>> Am 13.07.2021 08:49:24 schrieb Marcel Taeumel <u></u>:
<br><br>> Hi all!
<br><br>>
<br><br>> I would like to clarify (or re-arrange) the structure of the source tree
<br><br>> so that we can continue to work on existing and experiment on new flavors
<br><br>> of the VM. They would then better match our build structure:
<br><br>>
<br><br>> /src/plugins -> (same)
<br><br>>
<br><br>> /src/vm -> /src/vm.32bit.cog.v3
<br><br>> /stacksrc/vm -> /src/vm.32bit.stack.v3
<br><br>>
<br><br>> /spurstacksrc/vm -> /src/vm.32bit.stack.spur
<br><br>> /spurstack64src/vm -> /src/vm.64bit.stack.spur
<br><br>> /spursrc/vm -> /src/vm.32bit.cog.spur
<br><br>> /spur64src/vm -> /src/vm.64bit.cog.spur
<br><br>> /spursistasrc/vm -> /src/vm.32bit.sista.spur
<br><br>> /spursista64src/vm -> /src/vm.64bit.sista.spur
<br><br>>
<br><br>> /nsspurstacksrc/vm -> /src/newspeak.vm.32bit.stack.spur
<br><br>> /nsspurstack64src/vm -> /src/newspeak.vm.64bit.stack.spur
<br><br>> /nsspursrc/vm -> /src/newspeak.vm.32bit.cog.spur
<br><br>> /nsspur64src/vm -> /src/newspeak.vm.64bit.cog.spur
<br><br>>
<br><br>> /spurlowcodestacksrc/vm -> /src/lowcode.vm.32bit.stack.spur
<br><br>> /spurlowcodestack64src/vm -> /src/lowcode.vm.64bit.stack.spur
<br><br>> /spurlowcodesrc/vm -> /src/lowcode.vm.32bit.cog.spur
<br><br>> /spurlowcode64src/vm -> /src/lowcode.vm.64bit.cog.spur
<br><br>>
<br><br>> This would make 15 different *src folders disappear from the source tree's
<br><br>> toplevel. Flavor-specific plugin lists might be defined from within VMMaker
<br><br>> and generated into their respective src folders.
<br><br>>
<br><br>> Also, there would be a clear place for /src/vm.32bit.interpreter.v3 too
<br><br>> :-)
<br><br>>
<br><br>> Thoughts? Opinions? Objections?
<br><br>>
<br><br>> Best,
<br><br>> Marcel
<br><br>>
<br><br>>
<br><br><div dir="ltr"><div>Hi Marcel,</div><div><br></div>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.<div><br></div><div>Kind regards,<br>Jakob</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Di., 13. Juli 2021 um 10:53 Uhr schrieb Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>>:<br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex;border-left: 1px solid rgb(204,204,204);padding-left: 1ex;min-width: 500px"> <div><div id="gmail-m_-7017067204786552037gmail-m_-3179048113518960234__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: rgb(0,0,0);text-align: left" dir="ltr">
<br><br>                                        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....<div></div><blockquote type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<br><br>                        <p style="color:rgb(170,170,170);margin-top:10px">Am 13.07.2021 09:38:36 schrieb Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"><div id="gmail-m_-7017067204786552037gmail-m_-3179048113518960234__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: rgb(0,0,0);text-align: left" dir="ltr">
<br><br>                                        Ah, I noticed the pattern "../../platforms" (or similar). Well, by flattening the sources one level, that pattern would still work.<div><br></div><div><img id="gmail-m_-7017067204786552037gmail-m_-3179048113518960234ed7202a8-0934-403f-bf34-650bbd5267dc" src="cid:17a9f9a9520cb971f161" width="418" height="296"></img><br></div><div>Best,</div><div>Marcel</div><div></div>
<br><br>                                        <blockquote type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<br><br>                        <p style="color:rgb(170,170,170);margin-top:10px">Am 13.07.2021 09:22:24 schrieb Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"><div id="gmail-m_-7017067204786552037gmail-m_-3179048113518960234__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: rgb(0,0,0);text-align: left" dir="ltr">
<br><br>                                        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.<div><br></div><div><img id="gmail-m_-7017067204786552037gmail-m_-3179048113518960234dd295706-7c97-4601-9ebf-eb68b40f7140" src="cid:17a9f9a9520cb971f162" width="925" height="437"></img><br></div><div><br></div><div>Best,</div><div>Marcel</div><div></div>
<br><br>                                        <blockquote type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<br><br>                        <p style="color:rgb(170,170,170);margin-top:10px">Am 13.07.2021 08:49:24 schrieb Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"><div id="gmail-m_-7017067204786552037gmail-m_-3179048113518960234__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: rgb(0,0,0);text-align: left" dir="ltr">Hi all!<div></div><div><br></div><div>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:</div><div><br></div><div>/src/plugins -> (same)</div><div><br></div><div>/src/vm -> /src/vm.32bit.cog.v3</div><div>/stacksrc/vm -> /src/vm.32bit.stack.v3</div><div><br></div><div><div>/spurstacksrc/vm -> /src/vm.32bit.stack.spur</div><div>/spurstack64src/vm -> /src/vm.64bit.stack.spur</div></div><div>/spursrc/vm -> /src/vm.32bit.cog.spur</div><div>/spur64src/vm -> /src/vm.64bit.cog.spur</div><div><div>/spursistasrc/vm -> /src/vm.32bit.sista.spur</div><div>/spursista64src/vm -> /src/vm.64bit.sista.spur</div><div><br></div></div><div><div>/nsspurstacksrc/vm -> /src/newspeak.vm.32bit.stack.spur</div><div>/nsspurstack64src/vm -> /src/newspeak.vm.64bit.stack.spur</div></div><div>/nsspursrc/vm -> /src/newspeak.vm.32bit.cog.spur</div><div>/nsspur64src/vm -> /src/newspeak.vm.64bit.cog.spur<br></div><div><br></div><div><div><div>/spurlowcodestacksrc/vm -> /src/lowcode.vm.32bit.stack.spur</div><div>/spurlowcodestack64src/vm -> /src/lowcode.vm.64bit.stack.spur<br></div><div><div>/spurlowcodesrc/vm -> /src/lowcode.vm.32bit.cog.spur</div><div>/spurlowcode64src/vm -> /src/lowcode.vm.64bit.cog.spur<br></div><div><br></div></div></div><div>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.</div><div><br></div><div>Also<span style="font-size: 10pt">, there would be a clear place for /src/vm.32bit.interpreter.v3 too :-)</span></div></div><div><br></div><div>Thoughts? Opinions? Objections?</div><div><br></div><div>Best,</div><div>Marcel</div></div></div></blockquote></div></div></blockquote></div></div></blockquote>
<br><br>                                        </div></div></blockquote></div>
<br><br><u></u><u></u><u></u></div></blockquote></div></blockquote></div>
<br></marcel.taeumel@hpi.de></marcel.taeumel@hpi.de></marcel.taeumel@hpi.de></jakres+squeak@gmail.com></div></blockquote></div>