The macos build's "brew install" command has developed a
build failure without us being involved at all:
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /opt/homebrew
Could not symlink bin/pkg-config
Target /opt/homebrew/bin/pkg-config
is a symlink belonging to pkg-config@0.29.2. You can unlink it:
brew unlink pkg-config@0.29.2
This makes the macos build work again and implements the suggestions
brew prints when installing bison and flex, regarding PATH, LDFLAGS,
and CPPFLAGS.
Some downstream projects build avrdude and want to add their
own version information to the avrdude version to distinguish
their builds from others.
This adds a clean way to do that without needing to patch the
avrdude sources, for both cmake and automake based builds:
cmake -DEXTRA_VERSION:STRING=-arduino.1-rc1
../configure EXTRA_VERSION=-arduino.1-rc1
After building avrdude, the last line of "avrdude -?" will now
look similar to the following, depending on whether you are
building an avrdude git checkout or an avrdude release tarball:
avrdude version 8.0-20240901-arduino.1-rc1 (30e19f23), https://github.com/avrdudes/avrdude
avrdude version 8.1-arduino.1-rc1 (30e19f23), https://github.com/avrdudes/avrdude
There were several problems with page_erase():
- Read cache not invalidated on writes to boot and apptable
- PDI apptable and boot memories paged access can get addresses wrong
There were several problems with page_erase():
- Not working on UPDI eeprom/usersig memories: write a page of 0xff instead
- Read cache not invalidated on page erase
- PDI apptable and boot memories page erase possibly erases wrong page
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.
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.
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?
Build parallel port code on supported systems
Unsupported systems are:
* Windows operating system
* MacOS operating system
This means the CI can test
* native Linux builds (yes, even for arm systems)
Untested at this time are the BSDs.
Removes the dysfunctional Windows (since Windows XP) parallel port code,
and has the buildsystems fail Windows builds if parallel port builds are
requested (HAVE_PARPORT or --enable-parport).
https://github.com/avrdudes/avrdude/pull/1874#issuecomment-2275762550
This adds checks for zombie sourcecode problems, i.e. problems
we have tried to eliminate but which might be or have been
resurrected.
The example check is for the problematic
#include "ac_cfg.h"
with double quotes instead of <> which were identified as a
problem in https://github.com/avrdudes/avrdude/issues/1706
and then fixed.
