[OpenSmalltalk/opensmalltalk-vm] Add build.linux32generic and build.linux64generic to support stack VM… (#585)
… builds on non-x86/ARM architectures.
The intent is to support architectures such as https://wiki.debian.org/SupportedArchitectures You can view, comment on, or merge this pull request online at:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/585
-- Commit Summary --
* Add build.linux32generic and build.linux64generic to support stack VM builds on non-x86/ARM architectures.
-- File Changes --
A build.linux32generic/squeak.stack.spur/build/mvm (31) A build.linux32generic/squeak.stack.spur/makeallclean (15) A build.linux32generic/squeak.stack.spur/makealldirty (15) A build.linux32generic/squeak.stack.spur/plugins.ext (18) A build.linux32generic/squeak.stack.spur/plugins.int (38) A build.linux64generic/squeak.stack.spur/build/mvm (31) A build.linux64generic/squeak.stack.spur/makeallclean (15) A build.linux64generic/squeak.stack.spur/makealldirty (15) A build.linux64generic/squeak.stack.spur/plugins.ext (18) A build.linux64generic/squeak.stack.spur/plugins.int (38)
-- Patch Links --
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/585.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/585.diff
Is this just a naming issue? You chose "sqstkspurlinuxht" and "sqstkspur64linuxht", which looks like the ones from build.linux32x86 and build.linux64x64 respectively. What are the main differences between: - build.linux32generic and build.linux32x86 - build.linux64generic and build.linux64x64
Both use autoconf/configure already.
In the end, the names are somewhat bogus. Effectively, `linux` is for all unicies _except_ Solaris, because the person maintaining these files had too much trouble integrating the tiny diffs into the `build.linux*` structures.
I even think, it adds to the confusion already present…
I cannot make up my mind at the moment. maybe later¬
Definitely not just a naming issue. The idea is to pull out all of the architecture specific settings to get to a truly generic stack vm.
Ignore the --disable-dynamicopenssl and vm_variant= (that's part of the packaging work) but note the sse2 and 're-exec' stuff which is what needs to be eliminated if you're going to build for say MIPS/PPC/RISC-V:
diff build.linux64x64/squeak.stack.spur/build/mvm build.linux64generic/squeak.stack.spur/build/mvm 4a5
# Some gcc versions create a broken VM using -O2
22a24
--disable-dynamicopenssl \
24,25c26,27 < CC=clang \ < CFLAGS="$OPT -msse2" ---
CFLAGS="$OPT" \ vm_variant=spur64
and
diff build.linux32x86/squeak.stack.spur/build/mvm build.linux32generic/squeak.stack.spur/build/mvm 3,9d2 < case "`uname -m`" in # ensure we see x86 as machine type < i*86) ;; # we're good < *) if type i386 2>&1 >/dev/null; then < echo "Re-exec as x86" < exec i386 "$0" "$@" < fi ;; < esac 30a24
--disable-dynamicopenssl \
32c26,27 < CFLAGS="$OPT -msse2" ---
CFLAGS="$OPT" \ vm_variant=spur32
I understand that concern. But it's just putting on band-aid. (I'm removing myself from review, I think I'm biased in a certain way and I do not want to influence here further :) )
@krono I don't mind bias as this is just my take on how to accomplish it, in the least invasive way I could think of, without any knowledge of how we've arrived here re: mvm proliferation or any other competing concerns. I'm open to alternatives re: a better solution.
Let me rephrase my concern: If there cannot be a "build.win32generic", "build.win64generic", "macos64generic" etc., I don't see much benefit in generalizing the Linux build files to this degree. One could instead put efforts in writing CMake files for all platforms. :-) Anyway, if there is no urgent need to support non-x86/ARM platform in this generic, yet Debian-specific, way, I am not sure it is worth creating even more build directories at this point.
But this could pave the way for someone besides Eliot to start down the RISC-V road. Debian current supports RISC-V. Look at https://riscv.org/exchange/software/ +Non-C Compilers & Runtimes. IMHO, OpenSmalltalk should be on that list! -KenD
I totaly agree. Point is, my way of doing this would be completely different, and hence tarnish this conversation. Hence I'm recusing from this case ;)
Tobias, please express yourself.
Personally I think this is a good idea but would drop "generic"; it's too much to type. I'd call it build/linux86 (i.e. wait until after the srcFoo => src/Foo, build.Foo => build/Foo refactoring)
@pbella pushed 3 commits.
9b842da3925e631f821d160858e8c4dd6370f927 Revert "Add build.linux32generic and build.linux64generic to support stack VM builds on non-x86/ARM architectures." a5b539035abf13f665b7922f5045407e945cc0d3 Merge remote-tracking branch 'upstream/Cog' into Cog de7a493adbd095471f2223f83182ce4806cef48d Add (reworked) linux32 and linux64 to support stack VM builds on non-x86/ARM architectures.
I have updated the pull request as discussed. It is now based on the recent reorg by @marceltaeumel and includes related autoconf changes.
Is there any reason that this PR should *not* be merged now? Phil is working (with the encouragement of the Squeak oversight board) on updating the Debian squeak-vm package so that it will include the opensmalltalk-vm VMs in addition to the existing squeakvm.org classic VM. This PR is important for Phil's work, so it would be good to get in merged now if there are no compelling reasons not to do so. I have also tried merging this PR followed by a merge of my own two related PRs (590 and 591) and I found no problems or conflicts. So ... may I go ahead and merge this into the main Cog branch?
Well, *I* think it's a reasonable idea.
On 2021-09-06, at 6:25 PM, David T Lewis notifications@github.com wrote:
Is there any reason that this PR should not be merged now? Phil is working (with the encouragement of the Squeak oversight board) on updating the Debian squeak-vm package so that it will include the opensmalltalk-vm VMs in addition to the existing squeakvm.org classic VM. This PR is important for Phil's work, so it would be good to get in merged now if there are no compelling reasons not to do so. I have also tried merging this PR followed by a merge of my own two related PRs (590 and 591) and I found no problems or conflicts. So ... may I go ahead and merge this into the main Cog branch?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ESR: Emulate Slide Rule
If there are no objections and no further comments, I will merge this PR this weekend.
Merged #585 into Cog.
vm-dev@lists.squeakfoundation.org
-
David T Lewis -
Eliot Miranda
-
Ken Dickey
-
Marcel Taeumel
-
pbella
-
tim Rowledge -
Tobias Pape