Add make-dist support and github workflow

[bandoti]

This change adds a new github workflow for generating a distribution tarball containing required sub-modules, fixing #6 .

In addition, it fixes some build issues with MSYS2 related to header files referenced as symbolic links.

[bandoti]

@cyanogilvie

The make-dist support is working now. Please note that I had to remove the symlink behavior which tcl-tomlcrypt uses in order to be able to support the tarballs on MSYS2, as Windows does not play nicely with symlinks. In particular:

• Delete Makefile.teabase.in

• Modify Makefile.in to use path relative to builddir:
  include $(top_builddir)/teabase/Makefile

• Modify configure.ac to add teabase include path and reference teabase/Makefile directly:

  TEA_ADD_INCLUDES([-I$srcdir/teabase])
  ...
  
  AC_CONFIG_FILES([Makefile pkgIndex.tcl teabase/Makefile])
  

Another thing to note is that the action permissions had to be adjusted, and the token set, to allow pushes to the release:

    permissions:
      contents: write

  token: ${{ secrets.GITHUB_TOKEN }}

If you are happy with this change, I would be happy to make the similar changes to tcl-tomlcrypt supporting MSYS2. Also note I have the CI run and generated test release here:
https://github.com/TclMonster/parse_args/actions/runs/11730151951
https://github.com/TclMonster/parse_args/releases/tag/v0.5.1

[cyanogilvie]

Thanks for this, building make dist and proper github release support for all my packages has been on my TODO list for a while.

Handling the symlink issue on Windows is a tricky one. The symlinks are essential in the code - there are just way too many divergent copies of the teabase stuff for me to manage otherwise. I like the approach you've taken with the build system to get around requiring symlinks in that case, but there are other cases (some in other projects) that still require them. Perhaps having make dist resolve the symlinks as copies in the generated release tar file would at least allow the releases to be built on Windows.

I'd like to put a bit more thought into how best to handle this before merging. Perhaps there is a way to have the github release workflow build a Windows binary Tcl 8.6 and Tcl 9.0 (when I get to supporting that). Not really useful on Linux platforms (libc version and flavour differences), but binary packages seem to be more acceptable on Windows. Supporting building on Windows for all the packages I maintain is a permanent headache for me, since I don't use it myself and the delta to accommodate it is pretty large and compatibility breaks frequently. If the Windows build recipe could be baked into the release workflow, at least I'd know:

• each release actually builds on Windows
• anyone who has difficulty building on Windows themselves at least has the option of the prebuilt release

I last worked on Windows over two decades ago, but back then pre-built binary releases were normal and accepted (and often closed-source), but I'd appreciate your thoughts on that approach these days, as a current Windows Tcl dev.

[bandoti]

All fair points! My typical workflow is primarily building extensions using MSYS2—so generally the *nix builds work, aside from a few hiccups here-and-there. In this particular case I am using kitcreator to build which automatically downloads tarballs and builds with the standard TEA approach.

I think a nice solution would be to use the tcl-setup and tcl-build-extension that @apnadkarni created. This already does the heavy-lifting for setting up Tcl/Tk and building the extension on various environments. I am planning to use this for a few extensions once I have a bit of time to add support for the clang MSYS2 environment.

I suppose this PR might be a good place to introduce it? I am happy to make the change if you're on board.

I like the approach you've taken with the build system to get around requiring symlinks in that case, but there are other cases (some in other projects) that still require them.

This is probably one of those things to handle on a case-by-case basis. I am fine with the solution to copy files where the symbolic links are preferred.

[cyanogilvie]

The tcl-setup and tcl-build-extension workflow actions look like just the thing, if you want to have a go at applying them here that would be great.

I'm busy dusting off the Ck extension for tcltk-depot and attempting to move it to use the standard TEA tooling. I'm planning to use tcl-extension-template as the template for those parts, so I'll have a chance to play with those workflow actions (although I'm not sure whether this or the sampleextension on the core fossil is the preferred template).

[bandoti]

The tcl-setup and tcl-build-extension workflow actions look like just the thing, if you want to have a go at applying them here that would be great.

Will do—stay tuned. 🙂

I'm busy dusting off the Ck extension for tcltk-depot and attempting to move it to use the standard TEA tooling.

That looks really cool! Great that it supports pdcurses as well.