I think this is pretty innocuous, but since we're
so close to 2.3 release it should be reviewed.
Assigning to Martin since he's the configure
expert.

This simple patch adds an --enable-profiling flag
to configure.in.  It's just the first step - adding
-pg to compile and link lines if $CC understands
it.

Logged In: YES 
user_id=21627

I have several objections: For 2.3, it is a new feature,
which cannot be added at this time (changing the group to 2.4).

It then only works with gcc, as other compilers don't
recognize -pg.

In addition, I fail to see the rationale for this change:
You can already achieve the same effect by setting CC (and
perhaps CXX) before invoking configure.

Logged In: YES 
user_id=44345

2.4 is fine.  It should work with any compiler which understands
-pg.  If that's only gcc for now, that's the only one which it will
get set for.  Support for other compilers can be added later by
people with access to other compilers.

I believe it's worth adding as a configure flag because it makes
it more foolproof.  By configuring with -pg, all extension modules
built with this particular python executable will also get profiling
enabled.  That's not immediately obvious to everyone.  Also some
people seem to think that by adding -pg to an extension module's
compilation that they should get profiled results.  That only works
if the interpreter is compiled with -pg because it's during a
modified exit() call that the data gets written.

This only came up because one user is going through all sorts of
hoops to try and profile his extension module.  He's obviously
making mistakes.  I think it would be better to make it a more
foolproof exercise.

Logged In: YES 
user_id=44345

Checked in as configure.in 1.458 and configure 1.447.