[Python-Dev] Proper place to put extra args for building

[Brett C.]

Martin v. Löwis wrote:
> Brett C. wrote:
> 
>>The other option is to not make configure.in skip injecting arguments when a
>>pydebug build is done based on whether OPT is defined in the environment.  So
>>configure.in:670 could change to ``OPT="$OPT -g -Wall -Wstrict-prototypes"``.
> 
> 
> That's a procedural question: do we want to accept environment settings
> only when running configure, or do we also want to honor environment or
> make command line settings when make is invoked. IOW, it is ok if
> 
> export OPT=-O6
> ./configure
> make
> 
> works. But what about
> 
> ./configure
> export OPT=-O6
> make
> 
> or
> 
> ./configure
> make OPT=-O6
> 
> All three can be only supported for environment variables that are never
> explicitly set in Makefile, be it explicitly in Makefile.pre.in, or
> implicitly through configure.
> 

Hmm.  OK, that is an interesting idea.  Would make rebuilding a lot easier if
it was just an environment variable that was part of the default OPT value;
``OPT="$BUILDFLAGS -g -Wall -Wstrict-prototyping".

I say we go with that.  What is a good name, though?  PY_OPT?

> 
>>The line for a non-debug build could stay as-is since if people are bothering
>>to tweak those settings for a normal build they are going out of there way to
>>tweak settings.  Seems like special-casing this for pydebug builds makes sense
>>since the default values will almost always be desired for a pydebug build.
>>And those rare cases you don't want them you could just edit the generated
>>Makefile by hand.  Besides it just makes our lives easier and the special
>>builds even more usual since it is one less thing to have to tweak.
>>
>>Sound reasonable?
> 
> 
> No. I thought you were talking about extra args, such as -fbrett-cannon.

I am, specifically ``-DPy_COMPILER_DEBUG`` to be tacked on as a flag to gcc.

> But now you seem to be talking about arguments that replace the ones
> that configure comes up with. Either of these might be reasonable, but
> they require different treatment. Replacing configure results is
> possible already

I am only talking about that because that is how OPT is currently structured;
configure.in replaces the defaults with what the user provides if the
environment variable is set.  This is what I don't want.