Improve autotools build (part 2/n) #1695
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Yes CMake does build ps file. Example run from git main (Linux x86_64 github action build). It also installs ps file. |
ndim
force-pushed
the
improve-autotools-build-part-2
branch
2 times, most recently
from
eb8130a
to
849fa5e
Compare
|
Strange, somehow the auto-tools build is also broken on my FreeBSD 14 Release system (virtual machine under Proxmox PVE 8.0, Intel N100 mini PC). Two issues.
And it is the same for git main or avrdude-7.3 release. I remember it was working last time, probably on another FreeBSD system. Please check on your FreeBSD system as well. If it is broken, then please add the task to fix FreeBSD autotools build as well. BTW, I am using latest git main (5c61b9e) and not this PR. build log under FreeBSD 14 for git mainNo issues to use CMake. CMake build log of git main |
|
One thing to try on systems where GNU make is not the default Also, the non-libtool library needs to go. |
|
Ah, I see. Once I use gmake, the build is fine. Now the only issue is why libserialport is not detected. using gmake and the build is fine |
|
Not using pkgconfig for anything yet. |
I understand. On the other hand, I do not see why libserialport is special in this aspect, it is the same for other dependancies. BTW, it is a bit strange that I need to use |
gmake was basically already required before, in particular when trying to run parallel jobs ( |
ndim
force-pushed
the
improve-autotools-build-part-2
branch
from
849fa5e
to
77edcdb
Compare
ndim
force-pushed
the
improve-autotools-build-part-2
branch
4 times, most recently
from
84b2f2d
to
646423d
Compare
|
@ndim Just an advance warning that the team have started testing with a view to release v8.0 around the w/end 17/18 Aug. If you have time to bring this PR into a shape that we can merge even partial progress that would be brill (but no worries if not). |
Elaborate a bit more on the VERSIONINFO_* and versioninfo_* m4 macros. This should help me get back into things when I come back to this in a year or so and have forgotten most of the details.
Guard m4 macro calls with m4_pattern_forbid for all macros which do not come with Autoconf/Automake. All other macros might not be present on the system, and it is better to m4_pattern_forbid them and have autoreconf fail, than to have autoreconf generate a malformed broken configure script which then always fails with a weird error message.
As no-dist-built-files was only introduced in Automake 1.16.4, we cannot rely on that feature being present and need to continue using our own workaround. This hooks the dist-hook in a more robust fashion in the face of multiple dist-hook targets (and versioninfo.mk already uses one).
ndim
force-pushed
the
improve-autotools-build-part-2
branch
from
646423d
to
04c791f
Compare
As libtool is supposed to be able to build libraries for every target system, we delegate library building to libtool and stop building our own static libavrdude.a library. You can control whether the static/dynamic library is built by using the --(disable|enable)-(static|dynamic) configure flags.
This transfers the information from the CMakeLists.txt libavrdude VERSION and SOVERSION into the autotools configure script and (partly) uses the information to build the libavrdude.la libtool library. At this time, VERSION must always be SOVERSION.0.0 for this to work (and that is checked).
ndim
force-pushed
the
improve-autotools-build-part-2
branch
from
04c791f
to
c4d903e
Compare
|
@stefanrueger While there are a considerable number of things I still want to do (see all the empty checkboxes in the above comments), the commits currently in this PR's branch are relative incomplex and I have confidence in them. The one exception being the automatic transfer of library version information from cmake to autotools. That information transfer of the number "2" works, but the library version apart from the number "2" is certainly not a well-thought-out problem space. OK, this is a good first step. Oh, and the CI runs succeeding is a not a good indicator that everything here works as intended. E.g. are no CI checks yet which compare the build results from cmake and automake builds. So I am good with merging this as-is. If you want something else specifically quickly for the 8.0 release, tell me about it and I can try. |
|
First test under MSYS2 mingw64 -- OK Windows -- no building of shared library -- this is a known issue. |
|
Second test under Ubuntu 20.04 -- OK for build and installation process. There is an issue with the programming but it has nothing to do with this PR as git main also failed. Need to debug.It could be a problem of my AVRISPmkii clone as well. git main: |
|
@mcuee Thanks for testing. I will merge soon. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a continuation which is based on #1681 to keep the PR sizes manageable both for the submitter and the reviewers.
Starting this as a Draft PR, expect rebases and force-pushing, e.g. rebasing to main after PR #1681 has been merged to main.
Some goals for this second round of fixing the autotools build:
--enable-versioned-doc, have people use--docdirto deviate from the default docdir*.texifiles-Walloption_LIBRARIES)Concerning both cmake and autotools builds:
*.pcfiles to find our own dependenciesOptionally, move
$top_srcdir/src/configure.acto$top_srcdir/configure.ac:README.md,NEWS, and especiallyCOPYINGintomake disttarballmake checkruntools/test-avrdude, somake distcheckwould cover everything in CI builds and the compile and install stages will only need to run once duringmake distcheck(about halves the CPU cycles needed for autotools CI builds).tar.xzand the Github tarballs.tar.gz