It seems that the configure file on the default branch has been generated with autoconf 2.70. Autoconf 2.70 has not yet been released [1]. The differences between the generated configure files with 2.69 and 2.70 are a few lines [3] added by 2.70 with 'runstatedir' in them. The last old discussion on the usage of different autoconf versions [2] does not really answer the following question: I am using 2.69, should a commit that changes configure.ac respects the existing 'runstatedir' lines added by a previous commit or uses directly the configure file generated by 2.69 ? Xavier [1] http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/16193 [2] http://thread.gmane.org/gmane.comp.python.devel/135327 [3] diff -r fe168c2b5e95 configure --- a/configure Wed Jul 06 23:58:16 2016 -0700 +++ b/configure Fri Jul 22 14:49:31 2016 +0200 @@ -777,7 +777,6 @@ docdir oldincludedir includedir -runstatedir localstatedir sharedstatedir sysconfdir @@ -888,7 +887,6 @@ sysconfdir='${prefix}/etc' sharedstatedir='${prefix}/com' localstatedir='${prefix}/var' -runstatedir='${localstatedir}/run' includedir='${prefix}/include' oldincludedir='/usr/include' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' @@ -1141,15 +1139,6 @@ | -silent | --silent | --silen | --sile | --sil) silent=yes ;; - -runstatedir | --runstatedir | --runstatedi | --runstated \ - | --runstate | --runstat | --runsta | --runst | --runs \ - | --run | --ru | --r) - ac_prev=runstatedir ;; - -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \ - | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \ - | --run=* | --ru=* | --r=*) - runstatedir=$ac_optarg ;; - -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb) ac_prev=sbindir ;; -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \ @@ -1287,7 +1276,7 @@ for ac_var in exec_prefix prefix bindir sbindir libexecdir datarootdir \ datadir sysconfdir sharedstatedir localstatedir includedir \ oldincludedir docdir infodir htmldir dvidir pdfdir psdir \ - libdir localedir mandir runstatedir + libdir localedir mandir do eval ac_val=\$$ac_var # Remove trailing slashes. @@ -1440,7 +1429,6 @@ --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] - --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include]
On Jul 22, 2016, at 09:01, Xavier de Gaye <xdegaye@gmail.com> wrote:
It seems that the configure file on the default branch has been generated with autoconf 2.70. Autoconf 2.70 has not yet been released [1]. The differences between the generated configure files with 2.69 and 2.70 are a few lines [3] added by 2.70 with 'runstatedir' in them. The last old discussion on the usage of different autoconf versions [2] does not really answer the following question:
I am using 2.69, should a commit that changes configure.ac respects the existing 'runstatedir' lines added by a previous commit or uses directly the configure file generated by 2.69 ?
It looks like Matthias used a 2.70 for this commit:
https://hg.python.org/cpython/rev/78d2cb7f66b6
thus probably inadvertently introducing the unused "runstatedir" stuff.
Since 2.69 is the current version, it's fine to "auto-remove" them.
IIRC, some years ago when autoconf was releasing more often and there were multiple versions in use, we had a test in configure.ac to ensure that a particular version of autoconf was being used. That doesn't seem to be necessary but it's something to keep in mind if we do start seeing on-going problems with autoconf churn.
-- Ned Deily nad@python.org -- []
On Fri, 22 Jul 2016 at 06:02 Xavier de Gaye <xdegaye@gmail.com> wrote:
It seems that the configure file on the default branch has been generated with autoconf 2.70. Autoconf 2.70 has not yet been released [1]. The differences between the generated configure files with 2.69 and 2.70 are a few lines [3] added by 2.70 with 'runstatedir' in them. The last old discussion on the usage of different autoconf versions [2] does not really answer the following question:
I am using 2.69, should a commit that changes configure.ac respects the existing 'runstatedir' lines added by a previous commit or uses directly the configure file generated by 2.69 ?
If autoconf 2.70 is not released yet then it's fine to regenerate configure w/ 2.69. -Brett
Xavier
[1] http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/16193 [2] http://thread.gmane.org/gmane.comp.python.devel/135327 [3] diff -r fe168c2b5e95 configure --- a/configure Wed Jul 06 23:58:16 2016 -0700 +++ b/configure Fri Jul 22 14:49:31 2016 +0200 @@ -777,7 +777,6 @@ docdir oldincludedir includedir -runstatedir localstatedir sharedstatedir sysconfdir @@ -888,7 +887,6 @@ sysconfdir='${prefix}/etc' sharedstatedir='${prefix}/com' localstatedir='${prefix}/var' -runstatedir='${localstatedir}/run' includedir='${prefix}/include' oldincludedir='/usr/include' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' @@ -1141,15 +1139,6 @@ | -silent | --silent | --silen | --sile | --sil) silent=yes ;;
- -runstatedir | --runstatedir | --runstatedi | --runstated \ - | --runstate | --runstat | --runsta | --runst | --runs \ - | --run | --ru | --r) - ac_prev=runstatedir ;; - -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \ - | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \ - | --run=* | --ru=* | --r=*) - runstatedir=$ac_optarg ;; - -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb) ac_prev=sbindir ;; -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \ @@ -1287,7 +1276,7 @@ for ac_var in exec_prefix prefix bindir sbindir libexecdir datarootdir \ datadir sysconfdir sharedstatedir localstatedir includedir \ oldincludedir docdir infodir htmldir dvidir pdfdir psdir \ - libdir localedir mandir runstatedir + libdir localedir mandir do eval ac_val=\$$ac_var # Remove trailing slashes. @@ -1440,7 +1429,6 @@ --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] - --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include]
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On 07/22/2016 06:41 PM, Brett Cannon wrote:
On Fri, 22 Jul 2016 at 06:02 Xavier de Gaye <xdegaye@gmail.com <mailto:xdegaye@gmail.com>> wrote:
It seems that the configure file on the default branch has been generated with autoconf 2.70. Autoconf 2.70 has not yet been released [1]. The differences between the generated configure files with 2.69 and 2.70 are a few lines [3] added by 2.70 with 'runstatedir' in them. The last old discussion on the usage of different autoconf versions [2] does not really answer the following question: I am using 2.69, should a commit that changes configure.ac <http://configure.ac> respects the existing 'runstatedir' lines added by a previous commit or uses directly the configure file generated by 2.69 ?If autoconf 2.70 is not released yet then it's fine to regenerate configure w/ 2.69.
-Brett
Changeset 816ae3abd928 regenerated the configure script with 'runstatedir' again. AFAIK Autoconf 2.70 has still not yet been released. Please let us stick with 2.69.
Xavier
On Sep 11, 2016, at 16:17, Xavier de Gaye <xdegaye@gmail.com> wrote:
Changeset 816ae3abd928 regenerated the configure script with 'runstatedir' again. AFAIK Autoconf 2.70 has still not yet been released. Please let us stick with 2.69.
As far as I can tell, the spurious "runstatedir" doesn't affect Python builds. But I'll make sure to rerun autoconf and remove it before tagging for b1.
-- Ned Deily nad@python.org -- []
The correct way to solve this is probably to stop checking in the generated configure and generate it with a "blessed" autoconf version in the release tarballs.
On Sun, Sep 11, 2016, at 13:17, Xavier de Gaye wrote:
On 07/22/2016 06:41 PM, Brett Cannon wrote:
On Fri, 22 Jul 2016 at 06:02 Xavier de Gaye <xdegaye@gmail.com <mailto:xdegaye@gmail.com>> wrote:
It seems that the configure file on the default branch has been generated with autoconf 2.70. Autoconf 2.70 has not yet been released [1]. The differences between the generated configure files with 2.69 and 2.70 are a few lines [3] added by 2.70 with 'runstatedir' in them. The last old discussion on the usage of different autoconf versions [2] does not really answer the following question: I am using 2.69, should a commit that changes configure.ac <http://configure.ac> respects the existing 'runstatedir' lines added by a previous commit or uses directly the configure file generated by 2.69 ?If autoconf 2.70 is not released yet then it's fine to regenerate configure w/ 2.69.
-Brett
Changeset 816ae3abd928 regenerated the configure script with 'runstatedir' again. AFAIK Autoconf 2.70 has still not yet been released. Please let us stick with 2.69.
Xavier
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
2016-09-12 8:27 GMT+02:00 Benjamin Peterson <benjamin@python.org>:
The correct way to solve this is probably to stop checking in the generated configure
Please keep it, it's convenient :-)
and generate it with a "blessed" autoconf version in the release tarballs.
+1 for that: we should modify the release PEP for that?
Victor
The configure file on the default and 3.6 branches have been generated with autoconf 2.70 once again. This is annoying when you have to maintain patches to this configure file in order to build on a non supported platform.
Xavier
On Nov 22, 2016, at 11:06, Xavier de Gaye <xdegaye@gmail.com> wrote:
The configure file on the default and 3.6 branches have been generated with autoconf 2.70 once again. This is annoying when you have to maintain patches to this configure file in order to build on a non supported platform.
I'm sorry about that. I did promise to rerun with autoconf 2.69 before tagging the release so committers didn't have to worry about it but I didn't notice my note to do so until after 3.6.0b4 had already been tagged. I'll try to do better for rc1.
Perhaps another solution to the problem might be to not include the autoconf-generated changes in the patches and just always run autoconf before doing a build? That's what we suggest for patches submitted to the tracker.
And this might also be a candidate for handling in our upcoming new development workflow, i.e. something like having autoconf automatically be run as part of checkins. If it hasn't already been discussed there, it might be worth bringing up on the core-workflow mailing list.
-- Ned Deily nad@python.org -- []
On 11/22/2016 08:16 PM, Ned Deily wrote:
On Nov 22, 2016, at 11:06, Xavier de Gaye <xdegaye@gmail.com> wrote:
The configure file on the default and 3.6 branches have been generated with autoconf 2.70 once again. This is annoying when you have to maintain patches to this configure file in order to build on a non supported platform.
I'm sorry about that. I did promise to rerun with autoconf 2.69 before tagging the release so committers didn't have to worry about it but I didn't notice my note to do so until after 3.6.0b4 had already been tagged. I'll try to do better for rc1.
Perhaps another solution to the problem might be to not include the autoconf-generated changes in the patches and just always run autoconf before doing a build? That's what we suggest for patches submitted to the tracker.
And this might also be a candidate for handling in our upcoming new development workflow, i.e. something like having autoconf automatically be run as part of checkins. If it hasn't already been discussed there, it might be worth bringing up on the core-workflow mailing list.
-- Ned Deily nad@python.org -- []
From the configure logs since last july, it seems that Benjamin and Serhiy are the only one using autoconf 2.70:
changeset 102530:b04560c3ce69 - author Benjamin Peterson
changeset 103648:816ae3abd928 - author Serhiy StorchakaIf it is not too difficult to build autoconf 2.69 from source, then the solution could be that they switch to autoconf 2.69.
Xavier
I do not think we should require individual developers committing changes to configure.ac to use a particular version of autoconf when regenerating configure. That is a burden.
The solution to your problem is to maintain your patches _only_ against configure.ac and rerun autoconf using whatever version you need yourself.
If a release manager decides they want configure generated with a specific version of autoconf at release time, they should rerun that specific version of autoconf and commit the result _for the release_.
otherwise the checked in configure script exists entirely as a convenience. configure.ac is always the source of truth.
-gps
On Tue, Nov 22, 2016 at 11:38 PM Xavier de Gaye <xdegaye@gmail.com> wrote:
On 11/22/2016 08:16 PM, Ned Deily wrote:
On Nov 22, 2016, at 11:06, Xavier de Gaye <xdegaye@gmail.com> wrote:
The configure file on the default and 3.6 branches have been generated with autoconf 2.70 once again. This is annoying when you have to maintain patches to this configure file in order to build on a non supported platform.
I'm sorry about that. I did promise to rerun with autoconf 2.69 before tagging the release so committers didn't have to worry about it but I didn't notice my note to do so until after 3.6.0b4 had already been tagged. I'll try to do better for rc1.
Perhaps another solution to the problem might be to not include the autoconf-generated changes in the patches and just always run autoconf before doing a build? That's what we suggest for patches submitted to the tracker.
And this might also be a candidate for handling in our upcoming new development workflow, i.e. something like having autoconf automatically be run as part of checkins. If it hasn't already been discussed there, it might be worth bringing up on the core-workflow mailing list.
-- Ned Deily nad@python.org -- []
From the configure logs since last july, it seems that Benjamin and Serhiy are the only one using autoconf 2.70:
changeset 102530:b04560c3ce69 - author Benjamin Peterson changeset 103648:816ae3abd928 - author Serhiy StorchakaIf it is not too difficult to build autoconf 2.69 from source, then the solution could be that they switch to autoconf 2.69.
Xavier
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On 11/22/2016 08:16 PM, Ned Deily wrote:
On Nov 22, 2016, at 11:06, Xavier de Gaye <xdegaye@gmail.com> wrote:
The configure file on the default and 3.6 branches have been generated with autoconf 2.70 once again. This is annoying when you have to maintain patches to this configure file in order to build on a non supported platform.
Perhaps another solution to the problem might be to not include the autoconf-generated changes in the patches and just always run autoconf before doing a build? That's what we suggest for patches submitted to the tracker.
On 23 November 2016 at 22:49, Gregory P. Smith <greg@krypto.org> wrote:
The solution to your problem is to maintain your patches _only_ against configure.ac and rerun autoconf using whatever version you need yourself.
Would this solution (forget about regerating the files until build time) be enough Xavier?
FWIW I make heavy use of the Mercurial interactive patch mode. I use it to filter out any unnecessary generated changes, while selecting other generated changes relevant to a patch. I.e.
hg commit --interactive hg qrefresh --interactive
On 11/24/2016 02:51 AM, Martin Panter wrote:
FWIW I make heavy use of the Mercurial interactive patch mode. I use it to filter out any unnecessary generated changes, while selecting other generated changes relevant to a patch. I.e.
I did not know the hg interactive mode, thanks for the tip Martin. The point I am raising is not a problem I am supposed to have with configure (just a frustrating experience) but that configure is not correctly updated in the repository.
Xavier
On 11/23/2016 11:49 PM, Gregory P. Smith wrote:
I do not think we should require individual developers committing changes to configure.ac <http://configure.ac> to use a particular version of autoconf when regenerating configure. That is a burden.
I do not agree, configure is a file tracked in the mercurial repository and commit changes to this file must be correct and done with the right tool. If this is a burden for developers to use a particular version of autoconf, then a solution to our problem might be to stop tracking configure in the repository and update the Makefile to run autoconf whenever configure.ac is modified.
I know that tracking generated files is not pure, but it's very convenient, so please keep them: configure, Python/importlib.h, Python/importlib_external.h, etc.!
When testing Python on some "custom" operating systems, I already had enough issues to compile Python :-) For example, on OpenIndiana, Python wanted to rebuild the grammar but the system Python was 2.6 which didn't work (I don't recall the details). Moreover, the "make touch" command didn't work neither :-)
Victor
2016-11-24 8:51 GMT+01:00 Xavier de Gaye <xdegaye@gmail.com>:
On 11/23/2016 11:49 PM, Gregory P. Smith wrote:
I do not think we should require individual developers committing changes to configure.ac <http://configure.ac> to use a particular version of autoconf when regenerating configure. That is a burden.
I do not agree, configure is a file tracked in the mercurial repository and commit changes to this file must be correct and done with the right tool. If this is a burden for developers to use a particular version of autoconf, then a solution to our problem might be to stop tracking configure in the repository and update the Makefile to run autoconf whenever configure.ac is modified.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On Thu, 24 Nov 2016 12:22:00 +0100, Victor Stinner <victor.stinner@gmail.com> wrote:
I know that tracking generated files is not pure, but it's very convenient, so please keep them: configure, Python/importlib.h, Python/importlib_external.h, etc.!
When testing Python on some "custom" operating systems, I already had enough issues to compile Python :-) For example, on OpenIndiana, Python wanted to rebuild the grammar but the system Python was 2.6 which didn't work (I don't recall the details). Moreover, the "make touch" command didn't work neither :-)
Right, tracking those artifacts is a long standing policy and exists for good reasons. Our policy is that the committed changes should be done with the "right" version of the tool to minimize churn, and I think we should maintain that policy even if we sometimes screw up.
(I thought we had actually introduced a check for it in the Makefile, but I guess not...that would make it inconvenient for someone to intentionally use a different version for a custom build.)
--David
On Nov 24, 2016, at 10:00 AM, R. David Murray <rdmurray@bitdance.com> wrote:
Right, tracking those artifacts is a long standing policy and exists for good reasons. Our policy is that the committed changes should be done with the "right" version of the tool to minimize churn, and I think we should maintain that policy even if we sometimes screw up.
Agreed.
(I thought we had actually introduced a check for it in the Makefile, but I guess not...that would make it inconvenient for someone to intentionally use a different version for a custom build.)
Would it be possible to add a commit hook? It seems like that would be the correct place to catch it.
Eric.
On Nov 24, 2016, at 10:05, Eric V. Smith <eric@trueblade.com> wrote:
On Nov 24, 2016, at 10:00 AM, R. David Murray <rdmurray@bitdance.com> wrote:
(I thought we had actually introduced a check for it in the Makefile, but I guess not...that would make it inconvenient for someone to intentionally use a different version for a custom build.)
I'm quite sure we did have such a check back some years ago back when there were less compatible versions of autoconf in wide use. It could be restored if someone wants to write a patch.
Would it be possible to add a commit hook? It seems like that would be the correct place to catch it.
It could but I'm sure you'd agree this is not something we need to be spending time on with our soon-to-be-retired hg-based workflow. As I suggested earlier in this thread, if there is interest in doing something, it should be considered for the new git-based workflow and, "if it hasn't already been discussed there, it might be worth bringing up on the core-workflow mailing list".
-- Ned Deily nad@python.org -- []
середа, 23 листопада 2016 р. 08:38:40 EET Xavier de Gaye написано:
From the configure logs since last july, it seems that Benjamin and Serhiy are the only one using autoconf 2.70:
changeset 102530:b04560c3ce69 - author Benjamin Peterson changeset 103648:816ae3abd928 - author Serhiy StorchakaIf it is not too difficult to build autoconf 2.69 from source, then the solution could be that they switch to autoconf 2.69.
I don't know how this was happen. For now autoconf 2.69 is installed on all my computers.
participants (10)
-
Benjamin Peterson -
Brett Cannon -
Eric V. Smith -
Gregory P. Smith -
Martin Panter -
Ned Deily -
R. David Murray -
Serhiy Storchaka -
Victor Stinner -
Xavier de Gaye