[OpenSmalltalk/opensmalltalk-vm] Revise docs on HowToBuild on Windows: cygwin tools must be in PATH [ci skip] (PR #657)
Otherwise, `MAKEDEBUG.BAT` & Co. might fail if some tools (such as `tee`) are not found. You can view, comment on, or merge this pull request online at:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/657
-- Commit Summary --
* docs on HowToBuild on Windows: cygwin tools must be in PATH [ci skip]
-- File Changes --
M building/win32x86/HowToBuild (1) M building/win64x64/HowToBuild (1)
-- Patch Links --
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/657.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/657.diff
Please review this closely before merging!
Are we really expected to use the cygwin binaries for creating an MSVC build? I was already confused when following these steps that the output build files would not contain any debug symbols for Visual Studio. Luckily, there is cv2pdb which seems to do this job, but I wonder why nothing of this is mentioned in the existing instructions ... @eliotmiranda How does your build-and-debug process on Windows look like?
Hi Christoph, historically, we don't use M$ compilers, notably because of buggish pre-processor. We use the mingw layer as target architecture instead. Cygwin offers all the necessary tools to cross-compile for mingw target for a long time, so we used that. Nowadays, it could be wsl as well as it can perform cross-compilation for mingw target easily too. Now that Eliot added makefiles for using LLVM compiler, we could completely avoid mingw layer, but the makefiles still use some unixy commands, so we still need a unix layer; I guess that Eliot just reused the already existing cygwin dependency... If you want to replace it with something simpler (maybe msys minimal shell), you're welcome! Still, I find it nice to have a choice, compilers gradually exploit the presumed absence of undefined behavior more and more aggressively, compiler bugs happens too, we might also depend on some implementation details like stack handling, so keeping a mingw target (either thru gcc or clang) still has some value IMO.
Hi Nicolas, Hi Christoph,
On Fri, Nov 4, 2022 at 2:09 PM Nicolas Cellier ***@***.***> wrote:
Hi Christoph, historically, we don't use M$ compilers, notably because of buggish pre-processor. We use the mingw layer as target architecture instead. Cygwin offers all the necessary tools to cross-compile for mingw target for a long time, so we used that. Nowadays, it could be wsl as well as it can perform cross-compilation for mingw target easily too. Now that Eliot added makefiles for using LLVM compiler, we could completely avoid mingw layer, but the makefiles still use some unixy commands, so we still need a unix layer; I guess that Eliot just reused the already existing cygwin dependency...
Exactly. Lazy, but it saved me a lot of time.
If you want to replace it with something simpler (maybe msys minimal shell), you're welcome! Still, I find it nice to have a choice, compilers gradually exploit the presumed absence of undefined behavior more and more aggressively, compiler bugs happens too, we might also depend on some implementation details like stack handling, so keeping a mingw target (either thru gcc or clang) still has some value IMO.
Right. At the time Andreas wrote the Win32 subsystem there was no community edition of the M$ compilers; the only free option was gcc & mingw. So using the M$ compilers wasn't an option (and they weren't up to the job). Now things are different. But throwing away the mingw build is silly. It doesn't cost us anything. _,,,^..^,,,_ best, Eliot
Thanks for the pointers (and sorry for the delay)! It was not my intention to introduce a new build process at this moment, I just wanted to make explicit what was implicit before (that the msbuild build process depends on UNIX utilities). That's the only contribution of this PR. :-)
These days, Cygwin's packages are quite old. There is no recent Clang, for example. With Windows 11, I had to switch to MSYS2 because Cygwin's make stopped working for no obvious reason... - https://www.msys2.org/wiki/History/
MSYS2 works like a charm. We also use it in our GitHub Actions.
These days, Cygwin's packages are quite old. There is no recent Clang, for example. With Windows 11, I had to switch to MSYS2 because Cygwin's make stopped working for no obvious reason...
MSYS2 works like a charm. We also use it in our GitHub Actions.
It would be good to revise building/{win64,win32}/HowToBuild to describe the MSYS2 scheme. I'd like to use that too. Note that we use cygwin but with the Microsoft community tool chain using the clang compiler for Virtend. That works well for compiling Microsoft platform code (COM et al).
@eliotmiranda approved this pull request.
Merged #657 into Cog.
vm-dev@lists.squeakfoundation.org
-
Christoph Thiede -
Eliot Miranda
-
Marcel Taeumel
-
Nicolas Cellier