lclevy / ADFlib

A free, portable and open implementation of the Amiga filesystem
GNU General Public License v2.0
84 stars 29 forks source link

Autotools builds on MacOs, CygWin and msys2 #56

Closed t-w closed 1 year ago

t-w commented 1 year ago

Cont. of #33, see also #36

t-w commented 1 year ago

I tested this and for me this is OK., it can be merged.

According to the @kyz's comment (in #33), we rather keep it this way as msys and CygWin may need further work.

The change that could be done here is to separate msys2 and cygwin to a another workflow, let's say autotools-build-msys-cygwin.yml, and make it manual, so that it can be executed manually at least from time to time (as @kyz mentioned in this comment, the CygWin (installation) is very slow, also it is not the primary target...), and also further work on this can be done. Unless it is possible to do it independently for each job, but it seems to me it is not possible, it must be a separated workflow.

@kyz, do you want to complete this? I mean for now just setting up the workflow, ie. no more changes in cmake or autotools that can break other builds/systems. Unless eg. msys2 can be quickly fixed, then fine. But really, no big changes elsewhere. Not in this PR.

If not, I will do this and then close the 0.8.0.

One more note - the work on CI (here GH workflows) is a nasty job that require a lot of commits that must be pushed to be tested. So things like this should always be done in a separated branch and then usually squash-merged, to prevent long mess in the history, where half of the commits are correcting typos...

t-w commented 1 year ago

Quoting the comment from #33:

I've tried adding autotools builds for macos (homebrew) and windows (cygwin and msys2)

  • macos build works

OK. Great.

  • macos found that there is not always a gstdbuf command. Removed its usage

This is coreutils: $ port provides which gstdbuf /opt/local/bin/gstdbuf is provided by: coreutils but OK., let it be.

  • cygwin works
    • but it is very slow to install, can take 17 minutes, so currently disabled

I have just executed this - CygWin installation: ~3 min., tests: ~3:40s, dist check over 6 minutes. CygWin is slow in general (and disk i/o in particular) so this is kind of expected. But it doesn't seem that bad, it can be kept enabled, IMHO.

  • distcheck found that src/win32/nt4_dev.h was missing as a dependency of win32/adf_nativ.o

    • msys2 doesn't currently work
  • failing in examples tests. when comparing the output of commands vs heredoc in script, one of the two has CRLF line endings and the other doesn't, causing diffs to fail. one of the two will need to be switched to LF

This test is in general failing on windows (except for CygWin, which is kind of UNIX/POSIX...), it has to be corrected or will be disabled. While it is useful, it is problematic and time-consuming to maintain it - every change in the output has to be put back, verified etc. So far it required too much time. But if there will be less changes, it will be very useful so great that it was added.

Concerning testing "examples" - there was a simple tests of executing the utilities, checking just if they run and showing the output - and it was removed (ad727cb)... It has to be put back as it is also useful - as a basic test if the binaries and the library actually work.

  • also, when printing paths, "/tmp" changes somewhere to "D:/a/_temp/msys64/tmp", can probably be fixed by changing tmpdir if cd $tmpdir && pwd does not print the same value as $tmpdir

I do not have time to fix this, so for now I will keep this disabled - if it is not corrected.

t-w commented 1 year ago

I tried to make a manual workflow like here: https://build5nines.com/configuring-manual-triggers-in-github-actions-with-workflow_dispatch/ but it just does not work, nothing appears on the "actions" interface to start the workflow manually.

On this StackOverflow discussion, it seems that the change must be done in the default branch of the repo... What I do not like at all...

These "Actions" are really weird in some aspects, something that should be trivial (just a workflow without automatic triggers specified by "on") require some strange hacks...

I will eventually merge as it is (unless you have some tips how to set manual workflow...).

t-w commented 1 year ago

I just enable cygwin and I merge as it is for now. So there will be MacOs, CygWin and disabled (to fix) Msys2.

(I have couple of more updates in workflows in another branch, where I also brought back the deleted test for examples).