Brett C. wrote: > 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?
I think EXTRA_CFLAGS is common, and it would not specifically be part of OPT, but rather of CFLAGS. > 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. The question is whether the user is supposed to provide a value for OPT in the first place. "OPT" is a set of flag that (IMO) should control the optimization level of the compiler, which, in the wider sense, also includes the question whether debug information should be generated. It should be possible to link object files compiled with different OPT settings, so flags that will give binary-incompatible object files should not be in OPT. It might be desirable to allow the user to override OPT, e.g. to specify that the compiler should not use -O3 but, say, -O1. I don't think there is much point in allowing OPT to be extended. But then, it is already possible to override OPT (when invoking make), which might be enough control. 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