alienvalkyrie Reply To alienvalkyrie
Primary obstacle is that this check probably has to happen in configure, so that the correct executable can be written into the Makefiles, but at the same time, configure must be able to pass without Python for the purposes of building from tarballs.
It would be a lot easier, yet already a big improvement for the user, if we just supported passing python to use as parameter (env variable). That would avoid the detection code in configure, that would need to know if it really should detect (and set) python to use, or not.
./configure PYTHON="/home/cazfi/bin/the-improved-cazfi-python-4.5"
alienvalkyrie Reply To cazfi
It would be a lot easier, yet already a big improvement for the user, if we just supported passing python to use as parameter (env variable). That would avoid the detection code in configure, that would need to know if it really should detect (and set) python to use, or not.
Sounds reasonable. But. We should probably still check the version of the supplied Python executable, and that check would also have to happen in configure – which means we'd still have aforementioned problem of requiring Python when building from tarball.
What we'd want, ideally, is to
I don't think there's a way to do all of those things without checking at configure-time whether we're going to need Python (based on whether generated code is up to date), or having something special about the tarballs that makes --without-python implicit.
Reply To alienvalkyrie
having something special about the tarballs that makes --without-python implicit.
Lack of ".git" ? Though it might break someone unpacking the tarball to their *own* repository (hmm... actually, I think Debian does just that for maintaining their packaging)
This would be handy also for testing that the build works with different python versions. Just came to my mind as people are speaking of how "big" update just released python-3.11 is.
Maybe abandon the idea to work on this on autotools any more. For meson based build the feature seems easy to implement.
Follow-up to #44735. Figure out whether there is a reasonable way to try different Python executables for use in environments/distros that offer backports of newer versions as e.g. python3.5. If there is, implement that way.
Primary obstacle is that this check probably has to happen in configure, so that the correct executable can be written into the Makefiles, but at the same time, configure must be able to pass without Python for the purposes of building from tarballs.