-
Notifications
You must be signed in to change notification settings - Fork 143
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
Improve autotool build (part 1/n) #1681
Conversation
0b87bb0
to
1c51b11
Compare
314e31c
to
271bbca
Compare
271bbca
to
15cad97
Compare
Even though this is still a draft, it already looks very promissing, tested with MSYS2 mingw64.
|
15cad97
to
c12e2d3
Compare
@mcuee I believe the additional |
2e6d1af
to
96460b0
Compare
8544ce1
to
6b551fc
Compare
This draft PR seems to work pretty well under macOS Homebrew. Detailed build log under macOS 14.3.1 Homebrew, Mac Mini M1 2020
Results:
|
Some goals for this first round of fixing the autotools build:
Concerning both cmake and autotools builds:
|
That sounds cool. I am not sure what the best way is to generate these. Here the release procedure that I inherited from @dl8dtl
|
Other than this: I commend your thorough review of the autotool build process @ndim. Really appreciated. ... and should you get stuck at some point remember "perfect is the enemy of good" (the project is quite happy to merge a number of independent good improvements, they don't have to come in one go) |
Indeed. For example, the following two issues can be in another time.
|
This add some basic CI checks which exercise the autotools build: * make targets "all" "install" testing compilation and installation * run the same dry-run test-avrdude check as the cmake builds * make target "distcheck" testing that dist tarball contains all the necessary files
Remove unused unnecessary commented out build code from "src/configure.ac". I accidentally left those comments in commit d15c561.
6b551fc
to
94e1966
Compare
No issues found under MSYS2 mingw64. build log under MSYS2 mingw64
Result binary version info is fine. Note:
CMake build has the version
|
Not so sure if this can be improved or not. It seems to me Windows resources are not used for the mingw autotools build. Since this is not a regression, it can be sorted out in Part 2. |
Everything is good under macOS (14.3.1, Mac Mini M1 2020). |
I can also see that everything is fine under Linux from the github action run. The document build will be dealt with in part 2 (PR #1695) |
@ndim and @stefanrueger I am happy with this PR -- assuming this PR has no conflicts with PR #1688. |
Apropos Testing: I have verified this works on Arch Linux, Void Linux with musl, Debian 11, Fedora 39. The texi doc builds fail on FreeBSD 13.2. |
The cmake builds used the author date I have added autotools builds for Windows to the TODO list in Part 2. I had not tried Windows builds at all. I have no Windows systems, but Fedora has a nice mingw cross compilation environment. I have just seen the cmake build substitute a year in the RC file, that is what I have mentioned this. |
The exact markers for the build systems I have chosen so far ( I just wanted something short and distinct. We could also not add a build system marker for cmake and only have a marker for Autotools builds, put the marker in a different place in the string, etc. Or we could keep AVRDUDE_FULL_VERSION without a build system marker, and add the buildsystem information together with more detailed build information elsewhere, e.g. whether this was built with readline, linuxgpio with or without gpiod, libelf, libusb, etc. E.g. the
|
Add the GIT_COMMIT_HASH to the version message printed by "avrdude -?" and in the avrdude.conf avrdude_conf_version line. So the autotools buildsystem now produces the identical version message as the cmake buildsystem does.
7f21b55
to
a67c6ef
Compare
I like that idea! If that is not too complicated, how about having the detailed info as last action in
|
Isn't the usage() message already long enough as it is? I would think users run the usage message when they want to find out how to use the avrdude tool they have, not to find out detailed build information. My idea would be to add a separate CLI parameter along the lines of GNU tools' With the CLI tool and the library being separate binaries and possibly dynamically linked, it would be interesting to see version and build system info from both library and tool, with the library's info being passed through the ABI so that library users can also display that information. This makes this whole thing start to look basically like gphoto2's Anyway, this goes beyond this PR. Let me remove the commit with the buildsystem markers from this PR tomorrow (git revert or force push) when I am back at a computer, and postpone the implementation of a more elaborate build information message for after this PR #1681 and in or possibly even after PR #1695. |
Have the autotools place their m4 files into the auto-m4/ subdir to separate them from our own m4 files. Not using AC_CONFIG_MACRO_DIRS for backwards compatibility.
a67c6ef
to
8553d37
Compare
I agree. This is a good move. |
The project has been reluctant to introduce new options. But here the difficulty is more that the project doesn't have long options (yet), |
Anyway, the commit adding buildsystem markers to the The whole build information thing (baking some build information into library and tool, and having the tool show both) has been moved to PR #1698. |
I'm not sure, but I think this is somehow related to this PR …
|
That sounds strange. I have just tried under FreeBSD 14 release and a fresh clone of my fork, no issues to build avrdude using
|
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.
Once I reclone the repo, it works fine,
|
Just wondering if you see such issues when using CMake.
|
I do not think this is PR is directly linked to Issue #1706. 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.
|
This is consistent with a rogue old I am reading up on cmake to add a check for such rogue files, and to fix the sequence of directories the C preprocessor looks for |
This Draft PR addresses the Autotools build issues named in #1664 and other things.
I will keep this a Draft PR until development with force pushes and surrounding discussions have finished and I can mark it "Ready for review" so it can eventually be merged.