Skip to content
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

Fix cmake build errors related to ac_cfg.h #1707

Merged
merged 4 commits into from
Feb 28, 2024

Conversation

ndim
Copy link
Contributor

@ndim ndim commented Feb 25, 2024

This fixes a few errors related to how cmake builds deal with ac_cfg.h. This has been discussed in #1681 (comment) and following comments, and then in issue #1706.

  • While testing, I ran cmake . a few times which generates a cmake buildsystem inside the source tree. Some of those files still had to be added to .gitignore.

  • Using the identifier version inside src/main.c to refer to AVRDUDE_FULL_VERSION is about as confusing as using VERSION instead of AVRDUDE_FULL_VERSION was. So I removed char *version and just let the functions reference AVRDUDE_FULL_VERSION directly. I trust compilers these days to have all those references refer to the same bit of constant memory, and not allocate several copies of AVRDUDE_FULL_VERSION.

  • Fix cmake not finding the generated ac_cfg.h when the (often unused and unnecessary) src/ac_cfg.h does NOT exist. See commit message.

  • And most importantly, fix the C preprocessor mistakenly looking in src/ before build_$ostype/src/ when looking for ac_cfg.h: Change from #include "ac_cfg.h" to #include <ac_cfg.h> in all source files.

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
@ndim
Copy link
Contributor Author

ndim commented Feb 25, 2024

Note that this PR does not add checks to src/CMakeLists.txt which look for a src/ac_cfg.h file when building out of tree, and then abort the build if such a file is found.

Letting the C preprocessor look in the out of tree build directory first means such a check is not needed any more.

@mcuee mcuee added the bug Something isn't working label Feb 25, 2024
@ndim
Copy link
Contributor Author

ndim commented Feb 26, 2024

The issue of the rogue src/ac_cfg.h would probably have been an issue in autotools builds as well, but those have other issues with out-of-tree builds aborting at this time, so I have not run into those yet.

@mcuee
Copy link
Collaborator

mcuee commented Feb 27, 2024

Looks like a good change to me.

Tested under Windows with different build (autotools build under MSYS2 mingw64, CMAKE mingw64 build and CMAKE VS2019 build, no build issues found, the version info of the binaries generated is also correct.

@stefanrueger stefanrueger merged commit e5304a4 into avrdudes:main Feb 28, 2024
12 checks passed
@ndim ndim deleted the fix-cmake-builds-related-to-ac_cfg.h branch February 28, 2024 23:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants