error: use of undeclared identifier 'AVRDUDE_FULL_VERSION'

[dl8dtl]

          I'm not sure, but I think this is somehow related to this PR …

Everything works fine when I rund build.sh on a clone of the official AVRDUDE repo.
However, when running it on my private fork (where the official repo is only upstream remote), even with the same source tree as the official repo, I eventually get:

[ 94%] Built target libavrdude
[ 96%] Building C object src/CMakeFiles/avrdude.dir/main.c.o
/home/joerg/src/avrdude/src/main.c:55:23: error: use of undeclared identifier 'AVRDUDE_FULL_VERSION'
char * version      = AVRDUDE_FULL_VERSION;

Originally posted by @dl8dtl in #1681 (comment)

[dl8dtl]

Just turning it into an issue for easier tracking.
My current fork has stashed changes I'd like to preserve (but not commit yet), so cloning the repo anew isn't a good solution for me.
Also, I think we'd better know the reason for why this happens. Alas, I couldn't understand within 5 minutes last night what's going on here. ;-)

[dl8dtl]

For reference, here's the verbose build output for
./build.sh -f -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
logfile.txt

[mcuee]

I can reproduce the issue under Windows MSYS2 mingw64 build environment.

• Improve autotool build (part 1/n) #1681 (comment)

Repost of the above comment below.

Interestingly I just reproduced your issue under MSYS2 mingw64 with clone from official avrdude, and the solution is the same -- redo the clone. I am not so sure what is the issue though. Occassionally there is the issue of getting wrong version number. And the solution has always the same for me -- to delete the local repo and clone again.

Note: I have delete the build directory before the build but it does not help.

MINGW64 /c/work/avr/avrdude_test/avrdude_main
$ rm -rf build_mingw64_nt-10.0-22631/

$ ./build.sh
-- Building for: Ninja
-- The C compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/mingw64/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Git: C:/msys64/usr/bin/git.exe (found version "2.43.0")
-- Found FLEX: C:/msys64/usr/bin/flex.exe (found version "2.6.4")
-- Found BISON: C:/msys64/usr/bin/bison.exe (found version "3.8.2")
-- Looking for libelf.h
-- Looking for libelf.h - found
-- Looking for libelf/libelf.h
-- Looking for libelf/libelf.h - found
-- Looking for usb.h
-- Looking for usb.h - not found
-- Looking for lusb0_usb.h
-- Looking for lusb0_usb.h - found
-- Looking for libusb.h
-- Looking for libusb.h - not found
-- Looking for libusb-1.0/libusb.h
-- Looking for libusb-1.0/libusb.h - found
-- Looking for hidapi/hidapi.h
-- Looking for hidapi/hidapi.h - found
-- Looking for ftdi_tcioflush
-- Looking for ftdi_tcioflush - found
-- Configuration summary:
-- ----------------------
-- DO HAVE    libelf
-- DO HAVE    libusb
-- DO HAVE    libusb_1_0
-- DO HAVE    libhidapi
-- DON'T HAVE libftdi
-- DO HAVE    libftdi1
-- DO HAVE    libreadline
-- DO HAVE    libserialport
-- DISABLED   doc
-- DISABLED   parport
-- DISABLED   linuxgpio
-- DISABLED   linuxspi
-- ----------------------
-- Configuring done (9.3s)
-- Generating done (0.0s)
-- Build files have been written to: C:/work/avr/avrdude_test/avrdude_main/build_mingw64_nt-10.0-22631
[64/77] Building C object src/CMakeFiles/avrdude.dir/main.c.obj
FAILED: src/CMakeFiles/avrdude.dir/main.c.obj
C:\msys64\mingw64\bin\cc.exe -DCONFIG_DIR="\"C:/Program Files (x86)/avrdude/etc\"" -IC:/work/avr/avrdude_test/avrdude_main/build_mingw64_nt-10.0-22631/src -IC:/work/avr/avrdude_test/avrdude_main -IC:/work/avr/avrdude_test/avrdude_main/build_mingw64_nt-10.0-22631 -IC:/work/avr/avrdude_test/avrdude_main/src -IC:/msys64/mingw64/include/libusb-compat -O2 -g -DNDEBUG -std=gnu11 -Wall -Wextra -Wno-unused-parameter -MD -MT src/CMakeFiles/avrdude.dir/main.c.obj -MF src\CMakeFiles\avrdude.dir\main.c.obj.d -o src/CMakeFiles/avrdude.dir/main.c.obj -c C:/work/avr/avrdude_test/avrdude_main/src/main.c
C:/work/avr/avrdude_test/avrdude_main/src/main.c:55:23: error: 'AVRDUDE_FULL_VERSION' undeclared here (not in a function)
   55 | char * version      = AVRDUDE_FULL_VERSION;
      |                       ^~~~~~~~~~~~~~~~~~~~
[73/77] Building C object src/CMakeFiles/avrdude.dir/developer_opts.c.obj
ninja: build stopped: subcommand failed.
Build failed.

Once I reclone the repo, it works fine,

MINGW64 /c/work/avr/avrdude_test/avrdude_main
$ ./build.sh
-- Building for: Ninja
-- The C compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/mingw64/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Git: C:/msys64/usr/bin/git.exe (found version "2.43.0")
-- Found FLEX: C:/msys64/usr/bin/flex.exe (found version "2.6.4")
-- Found BISON: C:/msys64/usr/bin/bison.exe (found version "3.8.2")
-- Looking for libelf.h
-- Looking for libelf.h - found
-- Looking for libelf/libelf.h
-- Looking for libelf/libelf.h - found
-- Looking for usb.h
-- Looking for usb.h - not found
-- Looking for lusb0_usb.h
-- Looking for lusb0_usb.h - found
-- Looking for libusb.h
-- Looking for libusb.h - not found
-- Looking for libusb-1.0/libusb.h
-- Looking for libusb-1.0/libusb.h - found
-- Looking for hidapi/hidapi.h
-- Looking for hidapi/hidapi.h - found
-- Looking for ftdi_tcioflush
-- Looking for ftdi_tcioflush - found
-- Configuration summary:
-- ----------------------
-- DO HAVE    libelf
-- DO HAVE    libusb
-- DO HAVE    libusb_1_0
-- DO HAVE    libhidapi
-- DON'T HAVE libftdi
-- DO HAVE    libftdi1
-- DO HAVE    libreadline
-- DO HAVE    libserialport
-- DISABLED   doc
-- DISABLED   parport
-- DISABLED   linuxgpio
-- DISABLED   linuxspi
-- ----------------------
-- Configuring done (6.0s)
-- Generating done (0.0s)
-- Build files have been written to: C:/work/avr/avrdude_test/avrdude_main/build_mingw64_nt-10.0-22631
[77/77] Linking C executable src\avrdude.exe

Build succeeded.

Run

sudo cmake --build build_mingw64_nt-10.0-22631 --target install

to install.

[mcuee]

I do not think this issue is directly linked to @ndim's PR #1681.

• Improve autotool build (part 1/n) #1681

It may have something to do with git and avrdude's build script.

As mentioned before, I've encounter below issue as well under MSYS2 mingw64 and macOS Homebrew (Mac Mini M1). Re-clone the repo will sort out the issue.

avrdude binary has the wrong date info whereas avrdude.conf has the right date and git commit info.

[ndim]

How it is supposed to work

The first line of code in src/main.c is #include "ac_cfg.h" which on cmake builds, is actually generated by cmake from src/cmake_config.h.in and put into ${builddir}/src/ac.cfg.h.

There is no complaint from the C preprocessor that it cannot find ac_cfg.h, so the C preprocessor finds an ac_cfg.h somewhere in its include path.

The line in ac_cfg.h we are looking for is the #define AVRDUDE_FULL_VERSION line, and that is created from the cmake-config.h.in file's line

#define AVRDUDE_FULL_VERSION "@AVRDUDE_FULL_VERSION@"

which was added by me in PR #1681 commit cc94578 where I effectively just renamed that line from the old

#define VERSION "@AVRDUDE_FULL_VERSION@"

to make it clearer which kind of version an occurrence of VERSION somewhere in a C file refers to.

What happens on your system?

On my FreeBSD system, after a cmake -S . -B build_freebsd (or the corresponding cmake call from build.sh) I get a working ac_cfg.h:

% grep 'VERSION' build_freebsd/src/ac_cfg.h
#define AVRDUDE_FULL_VERSION "7.3-20240225 (20788712)"

@dl8dtl I presume in your affected private fork working dir, this same grep yields the following. Or is the version older?

% grep 'VERSION' build_freebsd/src/ac_cfg.h
#define VERSION "7.3-20240225 (20788712)"

Then the next check would be

% grep 'VERSION' src/cmake_config.h.in     
#define AVRDUDE_FULL_VERSION "@AVRDUDE_FULL_VERSION@"

which in your case might be

% grep 'VERSION' src/cmake_config.h.in     
#define VERSION "@AVRDUDE_FULL_VERSION@"

Unfortunately, the build logs never mention ac_cfg or cmake_config anywhere.

Maybe it could help forcing cmake to rebuild ac_cfg.h by removing build_freebsd/src/ac_cfg.h but @mcuee writes on his windows build he had the same problem even after removing the build directory...

I cannot see how src/main.c would be updated to use AVRDUDE_FULL_VERSION instead of VERSION, while src/cmake_config.h.in would still use VERSION, as that a single commit changing both.

Shooting in the dark, maybe running grep -r '\<VERSION\>' could help find the VERSION without AVRDUDE_FULL_VERSION (alongside many false positives from autotools generated build files).

Worst case, send me a tarball of the offending directory including all your local and private data. That would give me all your git history, stashes, and local files with weird stuff. (Note to self: Check that I can receive mails with 30+MB attachments.)

[dl8dtl]

There is no complaint from the C preprocessor that it cannot find ac_cfg.h, so the C preprocessor finds an ac_cfg.h somewhere in its include path.

That was actually the key to understand it.
The setup that works:

% find . -name ac_cfg.h
./build_freebsd/src/ac_cfg.h

The failing one:

% find . -name ac_cfg.h
./build_freebsd/src/ac_cfg.h
./src/ac_cfg.h

The src/ac_cfg.h file is presumably a leftover from an old non-CMake build. A gmake -i distclean removed all the remnants from the old autoconf build – and voila, build.sh works now.
Thanks for the insight!

[ndim]

Is it possible you have an older src/ac_cfg.h file lying around, e.g. from testing autotools builds? That could mistakenly be picked up instead of the proper build_freebsd/src/ac_cfg.h.

[ndim]

The two above comments are a good example for a race condition.

Anyway, thanks for pointing this out. There should be an automatic check for this kind of thing.

[ndim]

Wait a minute. There should not be a need for such a check.

The C preprocessor should just search the build_$ostype/src/ directory before the src/ directory when looking for a *.h file.

[dl8dtl]

Wait a minute. There should not be a need for such a check.

The C preprocessor should just search the build_$ostype/src/ directory before the src/ directory when looking for a *.h file.

OK, I reopen the issue tracker then. Alas, I don't have time right now for any testing.