-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI: test running the built avrdude executable #1888
CI: test running the built avrdude executable #1888
Conversation
26f9f29
to
988642e
Compare
A few things which turned up:
|
d4da86f
to
4331743
Compare
70b1024
to
ada1c9d
Compare
7c56a70
to
c3f387a
Compare
So I tried to reproduce MacOS build problems here. As it turns out, the macos builds (both cmake and automake) succeed and The actual problems turn out to be msvc+cmake (fails to install due to missing python dependency) and mingw (test-avrdude cannot write files to temp directory). |
Great finds. Will this PR, as a byproduct, run test-avrdude on most/all systems the CI builds avrdude for. Would be great!
Try adding |
This PR runs This PR also installs
That is the weird part, which got me stuck. I use |
I think we can skip this one (MSVC +CMake). |
With regard to Python and SWIG dependancy, we may want to install them explicitly in CI, at least for Linux and macOS. PR #1714 only installed them on Msys2-mingw64. Somehow last time when @dl8dtl and I tested the PR #1714, only Windows on ARM64 does not have Python installed. That is why PR #1714 actually disables Windows on ARM64 build (with MSVC + CMake). |
b2409ed
to
6c3a55d
Compare
You can not use the following method to install avrdude for homebrew under macOS. The following may actually break the system.
I am not so sure how homebrew does it though. |
For testing that the installed avrdude runs, it is not important where it is installed, just that it is installed. And whether the system may break later does not matter in a GitHub worker VM image which is thrown away seconds later. I can use
homebrew uses whatever |
I understand. Still probably you can use |
4a183e8
to
fbe0201
Compare
Example how I test under Windows. Build log with MinGW with Python/Swig for reference as well.
Using
|
Build log for macOS auto-tools with SWIG and Python. |
Build log with CMake, VS2022, Python and Swig under Windows 11. There is a bit of issue that the produced Build log
Location of the build results.
|
Use the same suffix string "-autotools" for "macos-x86_64-autotools" which the linux-x86_64-autotools build already uses.
be7441e
to
ba1547d
Compare
Use printf(1) to avoid possible echo(1) incompatibilities like special escape sequences and the like. Also, "\n\n" means two linefeeds, without any implicit linefeeds being added. Thought for the future: Perhaps test-avrdude should run isatty() and, if it is not a TTY, not wait for linefeeds at all in the non- interactive case?
The doc builds are a bit brittle at this time, and therefore do not work reliably with "make distcheck". Therefore this comments out "make distcheck" until the am doc builds have been fixed.
ba1547d
to
d1aea9f
Compare
This tries running the uninstalled avrdude executable, both with -? and for test-avrdude. Tests on installed avrdude are kept where they exist, but not added for all possible platforms. Quick table showing * -? testing of built avrdude (print the usage) * dryrun testing of built avrdude before installation * installation of avrdude * dryrun testing of installed avrdude and whether that happens/succeeds/fails: run test test -? built install installed linux-x86_64-autotools | yes | succ | yes | succ linux-x86_64 | yes | succ | yes | succ linux (cross-compile) | yes# | n/a | no | <-- macos-x86_64 | yes | succ | no | <-- macos-x86_64-autotools | yes | succ | no | <-- msvc | yes* | succ | broken | <-- mingw | yes | fail | no | <-- # Only on i386, as the armhf and arm64 executables are not runnable on the ubuntu-latest x86_64 worker. * Works on x86 and x64. Skipped on arm64 at this time. The arm64 executable is not runnable, possibly due to the old problem of an exe being built for the wrong architecture (which @mcuee mentioned somewhere). In summary, this should run as much as is possible at this time without introducing failures. In the future, after these failures are fixed, more tests can be added for a more complete coverage.
d1aea9f
to
c677974
Compare
This could be merged IMHO. It did not help with the MacOS problem, but discovered some Windows problems, but at least this PR now runs what tests can be run at this time. Three types of simple tests are run:
The remaining problems (installing and testing installed avrdude everywhere, general msys2 mingw test-avrdude failure to write to temp files, msvc arm64 executable cannot be run) can be fixed later in seperate PRs. Quoting the main commit's message:
|
@ndim Cool work! Thanks for this |
This PR tries to fix #1884.
As described in #1884 (comment), the goal is to make sure that all builds run the
tools/test-avrdude
script, and that thetools/test-avrdude
script fails if runningavrdude
fails.Then the problems with the macos automake builds might become visible, which in turn would allow fixing them.
Starting as a draft PR until it is ready to be merged.