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. _______________________________________________ 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