Closed AndyMender closed 1 year ago
No we are not going to have alternative build systems and we are not going to switch to cmake. I've looked at cmake before, and now considering we have easy cross compilation support off the packaged scripts in the release, I'm not going to add a dependency to the release build. There are less benefits to having cmake today than when we started.
You don't need autoreconf unless you are building from a git snapshot. No distros have come with patches either, so I guess they really don't bother running autoreconf. I guess a few distros have autoconf 2.71, which is interesting considering the release notes explicitly said there are breaking changes and it hasn't been out that long. Either the changes aren't a big deal, or they are just doing what they do. That said, we don't rely on much in configure.ac, so I suspect this will be easy enough to address. If you want, you can file issues on autoconf 2.71 so we can take a look.
Big thanks for the in-depth response! I agree in this case it wouldn't be much of a benefit to switch to cmake.
Regarding autoconf 2.71, I will take a look again and file a patch if I am able to.
I installed autoconf (version 2.71) and autoconf-archives (snapshot from 2022.02.11) to a local prefix, ran ./autogen.sh
and ./configure
again and it looks it was an issue with my local setup, not the repo.
Would there be any interest in providing a cmake-based configuration workflow in addition to the existing autotools setup?
I tried configuring 7kaa via
./autogen.sh
and noticed issues with some macros when using autoconf 2.71 (version 2.69 worked well). Having good experience with cmake and very bumpy experience with autotools, especially with the incompatibilities across versions, I think cmake might be a good long-term investment and I would be happy to help when I have time :).