[Python-Dev] configure on FreeBSD 7
I do not have this problem on FreeBSD 6.3-STABLE, but on my FreeBSD
7.0-STABLE I get this problem after running an identical ./configure:
[09:11] [EMAIL PROTECTED] (0) {0} % make
"Makefile", line 1192: warning: duplicate script for target "Modules/" ignored
"Makefile", line 1194: warning: duplicate script for target "Modules/" ignored
"Makefile", line 1196: warning: duplicate script for target "Modules/" ignored
"Makefile", line 1198: warning: duplicate script for target "Modules/" ignored
"Makefile", line 1200: warning: duplicate script for target "Modules/" ignored
"Makefile", line 1202: warning: duplicate script for target "Modules/" ignored
"Makefile", line 1204: warning: duplicate script for target "Modules/" ignored
"Makefile", line 1206: warning: duplicate script for target "Modules/" ignored
"Makefile", line 1208: warning: duplicate script for target "Modules/" ignored
Graph cycles through thread
make: don't know how to make threadmodule.c. Stop
line 1192 is:
Modules/ thread threadmodule.o: $(srcdir)/Modules/ thread threadmodule.c; $(CC)
$(PY_CFLAGS) -c $(srcdir)/Modules/ thread threadmodule.c -o Modules/ thread
threadmodule.o
On my 6.3 box it became:
Modules/threadmodule.o: $(srcdir)/Modules/threadmodule.c; $(CC) $(PY_CFLAGS)
-c $(srcdir)/Modules/threadmodule.c -o Modules/threadmodule.o
As you can see, some spurious 'thread' mentions got inserted.
Apparently this section is made by makedepend.
Has anyone else encountered this?
--
Jeroen Ruigrok van der Werven / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
No man is good enough to govern another man without the other's consent...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configure on FreeBSD 7
-On [20080412 09:32], Jeroen Ruigrok van der Werven ([EMAIL PROTECTED]) wrote: >Apparently this section is made by makedepend. I had no updates for makedepend or autotools, but somewhere along the full upgrade of all my ports makedepend suddenly started to behave, so some dependency must have caused the previous breakage. I wonder which though, since I forced a recompile of makedepend before emailing. Peculiar. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ The only trust in this world is that of steel... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] weird configure (autotools) setup
Why is CFLAGS in Makefile.pre.in specified as CFLAGS= $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS) whereas that will negate any CFLAGS you pass to configure? A normal call to configure (as ./configure --help also explains) can contain a CFLAGS specification, e.g.: CFLAGS="-compiler_options" ./configure --config_options Configure happily compiles and tests everything with the working CFLAGS (as evident in config.log), but when it comes to the output substitution it will, of course, not be overridden. Now, I realize that configure.in talks about BASECFLAGS and OPT, but neither of these are documented in the ./configure --help output, nor are they standard when it comes to autotooling. Passing CFLAGS is the defacto standard. Furthermore, when passing compiler options to OPT, these are NOT taken along in the configure tests, which means you might have passed faulty options but configure will not detect any problems with them. You will only encounter this when you start building. So is there any rationale for all this? -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Contentment that derives from knowing when to be content is eternal contentment... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] weird configure (autotools) setup
Jeroen Ruigrok van der Werven wrote: > Why is CFLAGS in Makefile.pre.in specified as > CFLAGS= $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS) > whereas that will negate any CFLAGS you pass to configure? There is a long history to that. The short version is that configure decides on its own what flags to pass to the compiler; that overrides any CFLAGS passed by the users. There have been multiple patches over the years to resolve this, eventually arriving at the status quo. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reserving an arg space for Jython
On Fri, Apr 11, 2008 at 4:03 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > I was also going to suggest a platform independent option. I like > -Xwhat-follows-is-impl-dependent. This would work just fine for us, and it makes sense to have it available for all implementations. If everyone likes this I will change the patch for CPython accordingly. How is -X is reserved for non-standard arguments -Frank ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Next monthly sprint/bugfix day?
On Thu, Apr 10, 2008 at 12:10 PM, Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> wrote: > On Wed, Apr 09 2008 at 11:12:58AM BRT, Trent Nelson <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Is there another online sprint/bugfix day in the pipeline? If not, can > > there be? ;-) > > +1. > > The Sao Paulo User's Group gathered to work on the last Bug Day, and I think > it was very productive (both for generating patches/comments and for us to > get more involved with Python core development). +1 from me. Rodrigo: Do you think GruPy-SP could coordinate with python-brasil to promote local participation in the next Bug Day? Regards, Daniel (from Brasília-DF) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Next monthly sprint/bugfix day?
On Sat, Apr 12 2008 at 10:12:18AM BRT, "Daniel (ajax) Diniz" <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 12:10 PM, Rodrigo Bernardo Pimentel > <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 09 2008 at 11:12:58AM BRT, Trent Nelson <[EMAIL PROTECTED]> > > wrote: > > > Hi, > > > > > > Is there another online sprint/bugfix day in the pipeline? If not, can > > > there be? ;-) > > > > +1. > > > > The Sao Paulo User's Group gathered to work on the last Bug Day, and I > > think > > it was very productive (both for generating patches/comments and for us to > > get more involved with Python core development). > > +1 from me. > > Rodrigo: Do you think GruPy-SP could coordinate with python-brasil to > promote local participation in the next Bug Day? Sure. When the next Bug Day is confirmed, we'll take it to python-brasil and the local user's groups. rbp -- Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> | GPG: <0x0DB14978> ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reserving an arg space for Jython
On Sat, Apr 12, 2008 at 5:42 AM, Frank Wierzbicki <[EMAIL PROTECTED]> wrote: > On Fri, Apr 11, 2008 at 4:03 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > > I was also going to suggest a platform independent option. I like > > -Xwhat-follows-is-impl-dependent. > This would work just fine for us, and it makes sense to have it > available for all implementations. If everyone likes this I will > change the patch for CPython accordingly. How is > > -X is reserved for non-standard arguments > Fine by me. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reserving an arg space for Jython
Brett Cannon schrieb: >> -X is reserved for non-standard arguments > > Fine by me. And implemented in r62293 (trunk) Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] generated NEWS files
>> #!/bin/sh >> REPOS="$1" >> REV="$2" >> USER="$3" >> PROPNAME="$4" >> >> /data/repos/projects/hooks/mailer.py propchange "$@" >> >> The script is the same mailer.py that is also invoked in post-commit. >> Can anybody see a problem with that? > > No, but how many parameters are passed to mailer.py? > > if cmd == 'commit': > if len(sys.argv) > 5: > usage() > if len(sys.argv) > 4: > config_fname = sys.argv[4] > elif cmd == 'propchange': > if len(sys.argv) < 6 or len(sys.argv) > 7: > usage() > # ... > > For commit, sys.argv must be <= 5, but for propchange sys.argv must == > 6, unless my tired eyes are reading that wrong. I don't know if the # > of args passed are the same in both cases or not. I've now looked into this; in Subversion 1.2, the number of arguments passed to post-revprop-change had changed, giving an addition "action" as $5. This broke the old mailer.py, which expected only 4 arguments. The rationale for this additional argument was to be able to tell whether a property had been added, modified, or deleted; if it was added, the old value was supplied as stdin (since revprops themselves aren't versioned). I've now updated mailer.py, merging our (few) changes into it. If anything seems broken now, please let me know. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 2.4.4/2.4.5 test_pty failure on Solaris 10
I know this is old stuff, but... I want to update our Python 2.4 installation at work from 2.4.2 to 2.4.5 (the latest 2.4 source release). I get a test failure for test_pty, an extra ^M at the end of one line. I don't get a failure in the 2.4.2 installation, but the 2.4.4 and 2.4.5 both fail this test. Looking at the code in test_pty.py, it appears to me that r43570 fixed things for OSF/1 and IRIX which both do weird things with output while breaking things for any other platform by suppressing the \r\n -> \n mapping which used to be performed for all platforms. So, for Solaris, that mapping doesn't happen and the actual and expected outputs don't agree. I'm not suggesting this needs to be fixed, I'm just looking for confirmation of my hypothesis if someone has a moment to compare the two revisions: http://svn.python.org/view/python/branches/release24-maint/Lib/test/test_pty.py?rev=43570&r1=42233&r2=43570 Thanks, Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6a2 execution times with various compilers
I did some more tests concentrating on GCC, partly based on the feedback I got, results at http://www.in-nomine.org/2008/04/12/python-26-compiler-options-results/ Executive summary: Python needs to be compiled with -O2 or -O3. Not doing so, no optimization level, results with GCC 4.2.1 in a doubling of execution time. Using just -O1 is still ~15% slower than using -O2. Using -mtune=native -march=native can shave of 0,1/0,2 seconds, but otherwise I did not find much difference in using having march or mfpmath present. Profile-guided optimization did not help much, as might be expected, it pushed about the same kind of optimization as the mtune/march combination. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ All know that the drop merges into the ocean but few know that the ocean merges into the drop. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reserving an arg space for Jython
On Sat, Apr 12, 2008 at 12:39 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Brett Cannon schrieb: > > >> -X is reserved for non-standard arguments > > > > Fine by me. > > And implemented in r62293 (trunk) Great, thanks! While I'd love to have *both* -X and -J, is that okay with the other devs? -Frank ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reserving an arg space for Jython
> Great, thanks! While I'd love to have *both* -X and -J, is that okay > with the other devs? +0. If we ever run out of letters for command line options to have to collect -J, we have deeper problems than having to coordinate with Jython whether the letter is still available. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] thoughts on having EOFError inherit from EnvironmentError?
http://bugs.python.org/issue1481036 Basically as things are now EOFError is on its own but often wants to be handled the same as other I/O errors that EnvironmentError currently covers. Many uses of EOFError in our code base do not provide it any arguments so it doesn't really fit the (errno, message [, filename]) tuple style that EnvironmentError promises. But we could fudge that with a reasonable default (whats reasonable?) if we rerooted this under EnvironmentError. Alternatively the bug suggests a new parent exception for EnvironmentError and EOFError both to inherit from. Last time changing the heirarchy around this came up there was pushback against adding yet another exception type so I'm thinking the simple re-rooting may be the best answer if anything is done at all. any thoughts? -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6a2 execution times with various compilers
On Sat, Apr 12, 2008 at 11:09 AM, Jeroen Ruigrok van der Werven < [EMAIL PROTECTED]> wrote: > I did some more tests concentrating on GCC, partly based on the feedback I > got, results at > http://www.in-nomine.org/2008/04/12/python-26-compiler-options-results/ > > Executive summary: Python needs to be compiled with -O2 or -O3. Not doing > so, no optimization level, results with GCC 4.2.1 in a doubling of > execution > time. Using just -O1 is still ~15% slower than using -O2. > > Using -mtune=native -march=native can shave of 0,1/0,2 seconds, but > otherwise I did not find much difference in using having march or mfpmath > present. > > Profile-guided optimization did not help much, as might be expected, it > pushed about the same kind of optimization as the mtune/march combination. > With gcc 4.1.3 i'm finding that profile guided optimization when trained on pybench or regrtest does make a measurable difference (2-5% overall time with 10-20% on some pybench tests). I haven't run benchmarks enough times to be confident in my results yet, I'll report back with data once I have it. I'm testing both pybench and regrtest as profiling training runs. I will check in a special makefile target for easy gcc profile guided compiles shortly so that those who want faster builds easily produce them. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reserving an arg space for Jython
On Sat, Apr 12, 2008 at 1:08 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Great, thanks! While I'd love to have *both* -X and -J, is that okay > > with the other devs? > > +0. If we ever run out of letters for command line options to have > to collect -J, we have deeper problems than having to coordinate > with Jython whether the letter is still available. +0 -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reserving an arg space for Jython
Frank Wierzbicki writes: > On Fri, Apr 11, 2008 at 4:03 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > > I was also going to suggest a platform independent option. I like > > -Xwhat-follows-is-impl-dependent. > This would work just fine for us, and it makes sense to have it > available for all implementations. If everyone likes this I will > change the patch for CPython accordingly. How is > > -X is reserved for non-standard arguments How about "-X is reserved for implementation-specific arguments"? Ie, I suppose that the intent is not that these arguments won't be standardized, it's that they be standardized by the affected implementations. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reserving an arg space for Jython
> How about "-X is reserved for implementation-specific arguments"? Ie, > I suppose that the intent is not that these arguments won't be > standardized, it's that they be standardized by the affected > implementations. Isn't that bikeshedding? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reserving an arg space for Jython
"Martin v. Löwis" writes: > > How about "-X is reserved for implementation-specific arguments"? > Isn't that bikeshedding? No. I think "implementation-specific" is definitely more accurate, and I was hoping the suggestion might get an immediate "good idea, implemented", from somebody already looking at that code. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
