add github workflow for CYGWIN-like platform MSYS2 on Windows

[jannick0]

This commit series serves the purpose to prepare for and add a github workflow for MSYS(2), a CYGWIN-like environment on Windows. It compiles fine, but reveals many test failures to be fixed.

NB:

• The entanglement with the win dir appears to be unneccassary and thus is removed to allow a pure unix configuration and build for MSYS and CYGWIN.
• As of now there are many failing tests, while one test (io-53.4.1) is omitted since it hangs as of now.
• For reference as to how CYGWIN and MSYS2 see need for heavily patching the tcl package which effectively ignore most of the #ifdef __CYGWIN__ branches. I believe that MSYS2 mostly relies on the CYGWIN patch.
• The msys2 workflow file added by the top of this branch is meant to be copied to the windows workflow (after testing)

I hope it is OK that this is a Github PR since this is about a github workflow which should be automatically triggered when opening this PR.

[nijtmans]

There's a "msys2-fixes-v001" branch in fossil now, with your PR. Two changes went right in Tcl now, the additional MSYSTEM environmentvariable, and the MSYS_ prefix in tcl.4: those don't harm any for the other platforms.

The entanglement with the "win" directory is only used to build the dde and registry extension. Although those 2 extensions are win32, they work fine with cygwin (and should work fine with msys2 too). Using dde, cygwin Tcl interpreters can communicate with win32 Tcl intepreters, that's usefull. And using registry, cygwin Tcl interpreters and access the Windows registry. I think that's usefull to keep, and is 100% separate from the build in the /unix directory.

Automatically determine --enable-64bit is a good idea, but it doesn't work yet together with the 'entaglement' with the "win" directory. Therefore I didn't take it over yet.

It's a pity that so many testcases still fail. This shows that msys isn't that compatible with unix (yet).

[jannick0]

Many thanks for looking at that!

The entanglement with the "win" directory is only used to build the dde and registry extension. Although those 2 extensions are win32, they work fine with cygwin (and should work fine with msys2 too).

Would you be able to provide a pointer to where the tcl package compiles out of the box for CYGWIN including running the test cases? I would be courious to see the logs for config, build and tests.

Automatically determine --enable-64bit is a good idea, but it doesn't work yet together with the 'entaglement' with the "win" directory. Therefore I didn't take it over yet.

It could serve as global test to make --enable-64bit obsolete. I thought about that, too, when putting the test together, but I prefer to leave it with you to use the test globally. Potential additional test whether the macro INTPTR_MAX is really defined by stdint.h might be helpful for, e.g., very exotic or old systems, while the macro should usually exist, though.

It's a pity that so many testcases still fail. This shows that msys isn't that compatible with unix (yet).

Well, that might well be. On the other hand CYGWIN itself applies heavy patches to (cf. references in the first comment)

• ignore the __CYGWIN__ branches in the code and
• ignoring the winextension target in the win folder. A similar patch MSYS2 does use. This suggests another interpretation. I am not advocating for any of the systems.

Again, this is why I would be intrigued to see how the tcl built on CYGWIN compiles (with winextensions) and tests out of the box. Any pointer to such a build for a most recent tcl package version? Many thanks.

[nijtmans]

out.txt

Here's the log when doing a cygwin "make test" for Tcl's unmodified core-8-6-branch (with -skip io-53.4.1, since this testcase fails on Cygwin too)

[jannick0]

Thanks - this is interesting. It looks like that similar tests fail for CYGWIN and MSYS2, so they are not so far apart from each other in this context I believe.

Would it be possible to see how the tcl package build was configured, too. Maybe in a Github Action which would be the most transparent way I guess.

[nijtmans]

The number of testcases failing on msys2 is now below 100. One of them because of this commit (https://core.tcl-lang.org/tcl/info/921cc1eb98e51b90). The fossil repository (which this GIT repository is a mirror or) now has a "cygwin" branch which contains all official cygwin patches (undoing most of the #ifdef CYGWIN stuff). And there is a "msys2-fixes-v001" branch, which contains the changes from this PR rebased to the "cygwin" branch (so, based on 8.6 too).

Most test-failures I see seem to be caused by lack of support for links on Windows. On cygwin it's a little bit better.

Thanks for your contribution.

B.T.W.: Is fossil ported to msys2?

[jannick0]

The number of testcases failing on msys2 is now below 100.

This is really good news - congratulations!

One of them because of this commit (https://core.tcl-lang.org/tcl/info/921cc1eb98e51b90).

I personally would use msys (or msys2) instead of msystem which would then be more in line with the unix nomenclature for MSYS2 animals.

Most test-failures I see seem to be caused by lack of support for links on Windows. On cygwin it's a little bit better.

This was exactly what I was expecting. The same thing for the sqlite testsuite on MSYS2.
Q: So would it be possible to have a tcl function which intrinsically checks at run-time if symbolic links work or not? (I am not sure if this gets into the realm of soft and hard links on Windows.) This function could then be used to test at check time if links work or not to decide if tests relying on links should be run or not. See here a related suggestion for the sqlite testsuite. As far as I can see the ball is not rolling there yet.

B.T.W.: Is fossil ported to msys2?

Yes. NB: Call fossil either in the MINGW32 or MINGW64 shell (but not in the MSYS shell, though):

• Note that there are the three shells MSYS, MINGW32 and MINGW64
• info on the fossil package for, say, MINGW64; download the fossil package for MINGW64 like so: pacman -S mingw-w64-x86_64-fossil (NB: pacman can be called in any of the 3 shells).
• how to use in Github Workflows CI and more detailed info

HTH - thanks again for your work.