Re: [python-committers] autoconf 2.70

[Ned Deily]

On Nov 24, 2016, at 10:05, Eric V. Smith  wrote:
> On Nov 24, 2016, at 10:00 AM, R. David Murray  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
  n...@python.org -- []

___
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/

Re: [python-committers] autoconf 2.70

[Eric V. Smith]

> On Nov 24, 2016, at 10:00 AM, R. David Murray  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. 
___
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/

Re: [python-committers] autoconf 2.70

[R. David Murray]

On Thu, 24 Nov 2016 12:22:00 +0100, Victor Stinner  
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
___
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/

Re: [python-committers] autoconf 2.70

[Victor Stinner]

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

Re: [python-committers] autoconf 2.70

[Xavier de Gaye]

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
___
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/

Re: [python-committers] autoconf 2.70

[Serhiy Storchaka]

середа, 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 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.

I don't know how this was happen. For now autoconf 2.69 is installed on all my 
computers.

___
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/