Re: automake 1.16.4 and new PYTHON_PREFIX
If anyone who weighed in on the Python prefix stuff (or didn't, for that matter) has a chance to try the new pretest at https://meyering.net/automake/automake-1.16g.tar.xz that'd be great. It'd be nice not to have to do another patch-up release. Thanks, Karl
Re: automake 1.16.4 and new PYTHON_PREFIX
Regarding PYTHON_PREFIX setting in automake, I've pushed a change that (I hope) reverts to the previous behavior of using the usual GNU prefix variables by default. It's attached. The new configure option --with-python-sys-prefix yields the the 1.16.4 behavior of using the sys.* Python values. The --with-python_[exec_]prefix options are still present and unchanged, setting the prefixes explicitly. It would be really fantastic if there could be some testing of this by other people before we push out another problematic release. Jim, could you roll a test release please? --thanks, karl. P.S. Oops, I see the brief description in the change is only supposed to be one line. Well, too bad, not going to adjust now. P.P.S. Although the diff shows nearly every line being changed, in fact most of the changes are about indentation. Unfortunately. But separating the formatting changes from the real changes proved too problematic and time-consuming, and I wanted to end up with a correctly-formatted source (as best I could manage). Sorry. ampy.diff Description: Binary data
Re: automake 1.16.4 and new PYTHON_PREFIX
I think we need an easy way to set a default for this behaviour from within configure.ac, similar to AC_PREFIX_DEFAULT(), so that the end-user doesn't have to pass a bunch of options to configure just to get the build to work sensibly. I have nothing against the idea, but my immediate goal is more basic: restore the previous behavior without losing the new configure benefits entirely. The current workaround I use is described below. Thanks for sending that code. --best, karl.
Re: automake 1.16.4 and new PYTHON_PREFIX
On 21-08-25 10:00, Karl Berry wrote:
| yf> Would keeping PYTHON_PREFIX but changing its default to the
| "classical" value be a working solution for this ?
|
| Yes, I think we should. And I think I should have been smart enough to
| realize that changing the default behavior was too risky in the first
| place. Apologies for that.
|
| My thought now is to add yet one more option, like
| --python-prefix-from-python, to get the new 1.16.4 behavior of using the
| "computed" sys.* values. Else go back to the previous $prefix-based
behavior.
|
| Does that sound sensible? A better name for the option?
|
| Joshua (or anyone), would you be willing to work on something like by
| any chance? Would be greatly, greatly, appreciated. I am way
| overcommitted right now (like all of us, I know ...).
|
| please keep the --with-python_prefix
|
| Definitely. --thanks, karl.
Currently overriding the python module path to install in the default
python module path in a manner that works for DESTDIR and distcheck
is a bit tricky, especially when using a different prefix.
I think we need an easy way to set a default for this behaviour
from within configure.ac, similar to AC_PREFIX_DEFAULT(), so that
the end-user doesn't have to pass a bunch of options to configure
just to get the build to work sensibly.
The current workaround I use is described below. If there was a
cleaner/more standardized mechanism built into automake / autoconf,
I'd use that.
Change the default prefix in configure.ac:
AC_PREFIX_DEFAULT([/opt/something])
Set defaults for make variables in configure.ac:
AC_SUBST([PY_OVERRIDE_BASE],
[$($PYTHON -c 'from distutils import sysconfig;
print(sysconfig.PREFIX)')])
dnl Note: Makefile sets PY_OVERRIDE_PREFIX from $(prefix) or
$(PY_OVERRIDE_BASE)
AC_SUBST([PY_OVERRIDE_EXTDIR],
[$($PYTHON -c 'from distutils import sysconfig;
print(sysconfig.get_python_lib(plat_specific=1,prefix="${PY_OVERRIDE_PREFIX}"))')])
Use a (non-portable) GNU make snippet in Makefile.am:
# Install python module to $(prefix) if it's not /opt/something,
# otherwise the default python prefix in $(PY_OVERRIDE_BASE).
#
PY_OVERRIDE_PREFIX := $(patsubst
/opt/something,$(PY_OVERRIDE_BASE),$(prefix))
pkgpyexecdir = $(PY_OVERRIDE_EXTDIR)/mymodule
This latter requires in configure.ac:
AM_INIT_AUTOMAKE([-Wno-portability])
Luke.
signature.asc
Description: PGP signature
Re: automake 1.16.4 and new PYTHON_PREFIX
yf> Would keeping PYTHON_PREFIX but changing its default to the "classical" value be a working solution for this ? Yes, I think we should. And I think I should have been smart enough to realize that changing the default behavior was too risky in the first place. Apologies for that. My thought now is to add yet one more option, like --python-prefix-from-python, to get the new 1.16.4 behavior of using the "computed" sys.* values. Else go back to the previous $prefix-based behavior. Does that sound sensible? A better name for the option? Joshua (or anyone), would you be willing to work on something like by any chance? Would be greatly, greatly, appreciated. I am way overcommitted right now (like all of us, I know ...). please keep the --with-python_prefix Definitely. --thanks, karl.
Re: automake 1.16.4 and new PYTHON_PREFIX
On 2021-8-25 10:14 , Karl Berry wrote: Ok, I guess we'll have to revert the Python change and make another release. I was worried about the change. But I am not sure of how best to deal with the intended benefits. Joshua, can you please take a look at these reports and advise? https://lists.gnu.org/archive/html/automake/2021-08/msg7.html https://lists.gnu.org/archive/html/automake/2021-08/msg6.html I guess the fundamental question is: Why are we asking python where it wants modules installed? If it's so we can install modules in a place where python will find them, it makes sense that $PYTHON_PREFIX may be distinct from $prefix. If it's so that we can install modules in a consistent subdir relative to the prefix, then we run into the problem that what python gives you is not always relative to the prefix (and isn't necessarily consistent). It seems like using a fixed subdir would solve that problem better than asking python. If reliance on the previous behaviour is widespread enough that the change is unacceptable, some alternatives might be to have different behaviour depending on whether the discovered python is in the configured prefix or not, or depending on whether or not python is a framework build. The downside is more special cases and more potential for confusion. Whatever else you decide to do, please keep the --with-python_prefix option. Having that makes it at least possible to install in the right place for framework builds, even if the defaults go back to being incorrect for that case. - Josh
Re: automake 1.16.4 and new PYTHON_PREFIX
Hello, Would keeping PYTHON_PREFIX but changing its default to the "classical" value be a working solution for this ? Best regards, Yvan Le 25 août 2021 07:08, j...@macports.org a écrit : On 2021-8-25 10:14 , Karl Berry wrote: > Ok, I guess we'll have to revert the Python change and make another > release. I was worried about the change. But I am not sure of how best > to deal with the intended benefits. > > Joshua, can you please take a look at these reports and advise? > https://lists.gnu.org/archive/html/automake/2021-08/msg7.html > https://lists.gnu.org/archive/html/automake/2021-08/msg6.html I guess the fundamental question is: Why are we asking python where it wants modules installed? If it's so we can install modules in a place where python will find them, it makes sense that $PYTHON_PREFIX may be distinct from $prefix. If it's so that we can install modules in a consistent subdir relative to the prefix, then we run into the problem that what python gives you is not always relative to the prefix (and isn't necessarily consistent). It seems like using a fixed subdir would solve that problem better than asking python. If reliance on the previous behaviour is widespread enough that the change is unacceptable, some alternatives might be to have different behaviour depending on whether the discovered python is in the configured prefix or not, or depending on whether or not python is a framework build. The downside is more special cases and more potential for confusion. Whatever else you decide to do, please keep the --with-python_prefix option. Having that makes it at least possible to install in the right place for framework builds, even if the defaults go back to being incorrect for that case. - Josh Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus. This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free.
RE: automake 1.16.4 and new PYTHON_PREFIX
Ok, I guess we'll have to revert the Python change and make another release. I was worried about the change. But I am not sure of how best to deal with the intended benefits. Joshua, can you please take a look at these reports and advise? https://lists.gnu.org/archive/html/automake/2021-08/msg7.html https://lists.gnu.org/archive/html/automake/2021-08/msg6.html Thanks, Karl
RE: automake 1.16.4 and new PYTHON_PREFIX
Hello, I concurr. In the case of the software I work on (code-saturne.org), we have in addition chosen not to version generated files, so as to be more consistent with a "maintainer mode" logic. Meaning that depending on the machine we install on, we can get a different behavior, as we cannot control which autotools version is installed. This had never been an issue in the last 15 years, a long as we updated our code when new autotools versions threw warning messages. So it was a bit of a surprise when I was bitten by this on a recent (Arch) Linux system. This definitely breaks quite a bit of packaging, along with our documentation. Best regards, Yvan Fournier -- Message: 1 Date: Mon, 23 Aug 2021 18:56:47 +0200 From: Víctor López To: automake@gnu.org Subject: automake 1.16.4 and new PYTHON_PREFIX Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed Hello, After reading the 1.16.4 patch notes regarding PYTHON_PREFIX and the discussion that originated the change in https://bugs.gnu.org/35322, I'm still not sure if this is expected: > cat configure.ac AC_INIT([foo], [1.0]) AM_INIT_AUTOMAKE([foreign]) AM_PATH_PYTHON AC_CONFIG_FILES([Makefile]) AC_OUTPUT > cat Makefile.am python_PYTHON = foo.py > touch foo.py > autoreconf -fi > ./configure --prefix=/tmp/foo && make install /usr/bin/install: cannot create regular file '/usr/lib/python3.9/site-packages/foo.py': Permission denied Sure, I can use the new flag --with-python_prefix=/tmp/foo, but I feel that these changes may have broken a lot of installation scripts and outdate the documentation of some packages. Is it intended to be this way? Thanks -- Subject: Digest Footer ___ Automake mailing list Automake@gnu.org https://lists.gnu.org/mailman/listinfo/automake -- End of Automake Digest, Vol 219, Issue 4 Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus. This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free.
