Improve and simplify configure.ac checks #89886
Comments
|
The autoconf-based build system has room for improvements. The configure.ac script can be simplified in several places by using AS and AC macros or by defining new custom macros. For example we have a lot of blocks that look like this: AC_MSG_CHECKING(for chroot)
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <unistd.h>]], [[void x=chroot]])],
[AC_DEFINE(HAVE_CHROOT, 1, Define if you have the 'chroot' function.)
AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
])The block has an issue, too. It does not use AC_CACHE to cache the result. The entire block can be replaced by a custom macro that takes care of everything and implements correct caching: PY_CHECK_FUNC([chroot], [#include <unistd.h>])We can also move several library and header checks from setup.py into configure.ac, e.g. check for soundcard.h or gdbm libs and headers. |
tiran
added
type-feature
tiran
added
build
|
The first PR adds helper macros, AC_CACHE_CHECK() [1] and AS_VAR_IF() [2]. It also unified internal variables to use format "ac_cv_func_$funcname", "ac_cv_func_lib_$library_$funcname", or "ac_cv_header_$headername_h". "ac_cv" stands for autoconf cached value. AC_CACHE_CHECK() replaces AC_MSG_CHECKING() and AC_MSG_RESULT(). The syntax is AC_CACHE_CHECK([text], [cache variable], [body]) where body is only excecuted when the cache variable is not set. The body has to set the cache variable to yes or no. Any output and AC_DEFINE must occur outside the body. AS_VAR_IF() is a nicer way to write if test $variable = value; then; fi. [1] https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Caching-Results.html#Caching-Results |
|
#73627 introduces forward compatibility issues with autoconf 2.71. I took the output of autoupdate and resolved all warnings. |
|
AC_CHECK_TYPE is obsolete and it's use is discouraged. There are some gotchas we need to check before switching to AC_CHECK_TYPES. See: |
|
In the conversion to PY_CHECK_FUNC, there's a mistake in HAVE_EPOLL. Python 3.10.1 defines HAVE_EPOLL by checking for the The effect is that |
|
Thanks William! |
…n#105062) Autoconf 2.70 macros are picky about argument quotation.
Quoting autoconf (v2.71):
All current systems provide time.h; it need not be checked for.
Not all systems provide sys/time.h, but those that do, all allow
you to include it and time.h simultaneously.
Quoting autoconf (v2.71):
All current systems provide time.h; it need not be checked for.
Not all systems provide sys/time.h, but those that do, all allow
you to include it and time.h simultaneously.
(cherry picked from commit 9ab587b)
Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
Quoting autoconf (v2.71):
All current systems provide time.h; it need not be checked for.
Not all systems provide sys/time.h, but those that do, all allow
you to include it and time.h simultaneously.
(cherry picked from commit 9ab587b)
Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
Co-authored-by: Christian Heimes <christian@python.org>
Co-authored-by: Christian Heimes <christian@python.org>
|
autoconf bumping to 2.71+ is a little annoying because LTS ubuntu 20.04 only ships with should this have landed in 3.12 which is already in beta freeze? I'm building this for deadsnakes and it'd kind of suck to not ship 3.12 for ubuntu 20.04 especially when 3.12b1 built cleanly |
Perhaps you are misunderstanding something. The generated IOW: You don't need GNU Autoconf at all for a clean build. |
|
part of debian packaging is to regenerate configure |
They can still do that with autoconf 2.69. There is no hard requirement to use 2.71. We only require 2.71 for CPython development. Debian should be all ok with 2.69. |
|
the sources were updated to require 2.71 in #105207 |
For CPython development, yes. |
|
Ah, there's a requirement check in the configure.ac script. Perhaps we can loosen that. |
yes that's the one I've been referring to |
erlend-aasland
added
3.12
--with-dyldoption #29500Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
--with-dyldoption #29500The text was updated successfully, but these errors were encountered: