Use libtoolize --force to ensure it updates m4 directory with the
latest files. Add an option "release" to the autogen.sh script that
checks the versions of the input tools, so that we know they are always
using the latest version for each release.
Ensure that ltmain.sh gets copied, not symlinked, like we do with
automake artifacts.
PR-URL: https://github.com/libuv/libuv/pull/675
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The serial-tests option is available in automake v1.12, not v0.12.
PR-URL: https://github.com/libuv/libuv/pull/113
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
This effectively undoes the following commits:
a97685e build: add automake serial-tests version check
e4c1483 build: serial-tests was added in automake v1.12
After much trial and error I've come to the conclusion that you cannot
reliably test for the automake version inside configure.ac itself.
Feature checks (testing for the presence of macros with m4_ifdef) is
not reliable when the macro is "lazy-loaded" by aclocal: m4 won't see
its definition unless it's actually used in configure.ac, hence checking
for obsolete macros like AM_ENABLE_MULTILIB and AM_WITH_REGEX is not a
reliable proxy for the automake version - both are are lazy-loaded.
That's why this commit moves the version check to autogen.sh, creates
a m4 file with automake options on the fly and includes that in
configure.ac.
Thank you, automake maintainers, for making hard what should be easy.
That's an hour of my life I won't be getting back!
Switch to the build tool everyone loves to hate. The Makefile has
served us well over the years but it's been acquiring more and more
features that autotools gives us for free, like easy static+shared
library building, sane install targets, and so on.
This commit drops MinGW support. If there is demand for it, we'll
re-add it.
