Directly use the AVRDUDE_FULL_VERSION macro instead of first
defining an initialized variable which is never changed and
then using that variable.

This means one less layer of indirection both for the computer
and for the programmer to go through when trying to understand
the code.

When there is no `src/ac_cfg.h` (e.g. a fresh `git clone` or after
a working dir cleanup like `git -f -d -x`), running `cmake` will
complain about not being able to find `ac_cfg.h`.

This is probably because cmake looks for source files in the
`CMAKE_CURRENT_SOURCE_DIR`, but when cmake creates `ac_cfg.h`
it does so ´CMAKE_CURRENT_BINARY_DIR`, which is often different.

Anyway, this makes the location of files generated by `configure_file`
explicit as `CMAKE_CURRENT_BINARY_DIR`, and uses that same location
in the source file list for the `libavrdude` target (instead of just
`ac_cfg.h` with the implicit `CMAKE_CURRENT_SOURCE_DIR`) and adds the
same source file to the `avrdude` target to allow cmake to determine
the dependencies properly.

As it can happen that there is a leftover `src/ac_cfg.h` when
running an out of tree cmake build (you might have run `cmake .`
or `./src/bootstrap`), the out of tree cmake build must look
for `ac_cfg.h` in its builddir first (e.g. `build_linux/src/`).

Otherwise the cmake build picks up and uses whatever data happens
to be in `src/ac_cfg.h`.

Both the MSVC and GCC C processors are documented to look in the
location of the `#include` directive for the included file first
for double quoted includes, so the old `#include "ac_cfg.h"` was
exactly the wrong thing to do. clang probably does the same, and
ISO C specifies the sequence of places to look for include files
as implementation defined.

So this changes all occurrences of `#include "ac_cfg.h"` to
`#include <ac_cfg.h>` which follows the sequence of `-I` or `/I`
directives as cmake builds add via `include_directories` or
`target_include_directories`.

Fixes: avrdudes#1706

This executes five tests for typical programming tasks:
  - Write/verify a "difficult" sketch to flash: two code sections and one
    data section separated by "holes" of different sizes
  - Dump all flash, eg, to make a backup
  - Write/verify a "difficult" eeprom data file with holes
  - Dump all eeprom, eg, to make a backup
  - Chip erase (bootloaders are expected to page erase flash apart from
    the bootloader itself) and spot check whether flash was erased

The reported times are realistic times with overhead of starting avrdude,
resetting the board via DTR/RTS, establishing comms, including erasing the
flash before writing/verifying the sketch and disengaging the chip.

$ test-avrdude -b -d 0 \
  -p "u7.7/weu-jPrac -c urclock -P ch340 -p m328p -b 1000000" \
  -p "u7.7/-eu-jPrac -c urclock -P ch340 -p m328p -b 1000000"

Testing avrdude version 7.3-20240225 (2078871)
Prepare "u7.7/weu-jPrac -c urclock -P ch340 -p m328p -b 1000000" and press 'enter' or 'space' to continue. Press any other key to skip
✅   2.174 s: flash -U write/verify holes_rjmp_loops_32768B.hex
✅   1.339 s: flash -U read all flash
✅   1.415 s: eeprom -U write/verify holes_pack_my_box_1024B.hex
✅   1.034 s: eeprom -U read all
✅   1.604 s: chip erase and spot check flash is actually erased
✅   7.566 s: benchmark for u7.7/weu-jPrac -c urclock -P ch340 -p m328p -b 1000000
Prepare "u7.7/-eu-jPrac -c urclock -P ch340 -p m328p -b 1000000" and press 'enter' or 'space' to continue. Press any other key to skip
✅   2.001 s: flash -U write/verify holes_rjmp_loops_32768B.hex
✅   1.333 s: flash -U read all flash
✅   1.405 s: eeprom -U write/verify holes_pack_my_box_1024B.hex
✅   1.029 s: eeprom -U read all
✅   1.618 s: chip erase and spot check flash is actually erased
✅   7.386 s: benchmark for u7.7/-eu-jPrac -c urclock -P ch340 -p m328p -b 1000000

Note the benchmark line with the cumulative time for all five tasks

Uppercase names are typically used for environment variables in bash

The cumulative time for typical user tasks depends on the flash and EEPROM
size of the part. This commit computes a size-normalised time. Lower is
better. This avrbench number still depends on the part, but less so than
the cumulative time of the tasks.

The summary line is put in vertical bars to make creation of markdown
tables easier.

…o-ac_cfg.h

Fix cmake build errors related to ac_cfg.h

Add benchmark option `-b` for `test-avrdude`

Both these functions are called at verbosity level DEBUG and above,
so they must not produce INFO level messages.

Supposed to fix issue avrdudes#1726

Some messaging needs a functionality to end an open line, so that the next
message starts at the left margin, ie, the ability to print a \n if and
only if the last printed character was not already a \n.

This used to be effected by \v as first char in the message format.

This commit introduces a dedicated lmsg_xyz() set of messaging functions
that utilises a MSG2_LEFT_MARGIN flag to enforce a left margin start for
the message.

Replace msg_info() by msg_debug() in jtag3_prmsg() and jtag3_prevent()

Closes avrdudes#1726

…sage

Remove unused avrdude_message()

Fixes avrdudes#1719

This is pointed out by @umbynos during the review of PR avrdudes#1690

Provide lmsg_xyz() functions to start message at left margin

Document progress reporting in source code

Change return type for avr_(ms|us)timestamp() to uint64_t

To use Static Libs for macOS arduino_packing build

These are debugging functions, and not supposed to print at
MSG_INFO level.

SPI programming cannot disable SPI programming for the part configuration.
Hence. when another programming interface disables SPI that very same
interface can enable SPI again. The warning disabling SPI might brick the
part is therefore incorrect.

See avrdudes@9616b37

Co-authored-by: Umberto Baldi <[email protected]>

Fix message levels in jtag3_print_data()

…-check

Consult -F option when signature cannot be read

…starts_set

Check all programmer ids for exact match

Update avrintel files

It's been deprecated for a while now.

libgpiod in version 2 or above introduced an API change which results
in compile error with the current code.

This commit adds some glue magic for the newer versions and
tries to detect the used libgpiod version based on the information
available in the pkg-config files.

At the moment, this eliminates the possibility to statically link
against this library.

Signed-off-by: Michael Heimpold <[email protected]>

better doc

…ullups

Add buspirate hiz and pullups feature

Add support for libgpiod v2+ API

Remove deprecated ucr2 part

Move static buffer to PDATA region in buspirate.c