Re: [python-committers] autoconf 2.70

2016-11-23 Thread Gregory P. Smith 
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  wrote:

> On 11/22/2016 08:16 PM, Ned Deily wrote:
>  > On Nov 22, 2016, at 11:06, Xavier de Gaye  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
>  >   [email protected] -- []
>  >
>
>  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 Storchaka
>
> If 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
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] autoconf 2.70

2016-11-23 Thread Victor Stinner 
2016-11-23 23:49 GMT+01:00 Gregory P. Smith :
> The solution to your problem is to maintain your patches _only_ against
> configure.ac and rerun autoconf using whatever version you need yourself.

I agree :-)

Victor
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] autoconf 2.70

2016-11-23 Thread Martin Panter 
>> On 11/22/2016 08:16 PM, Ned Deily wrote:
>>  > On Nov 22, 2016, at 11:06, Xavier de Gaye  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  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
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] autoconf 2.70

2016-11-23 Thread Xavier de Gaye 

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  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
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/